4.3 KiB
I’m sharing this because the current state of runtime security, VEX maturity, and SBOM/attestation tooling is actively shaping how buyers prioritize verifiable evidence over vendor claims — and the latest product releases and community discussions show real gaps you should be tracking.
When vendors talk about runtime protection and exploitability insights, the focus is increasingly on live telemetry, threat detection, and actionable blocking, but the specifics vary in documentation and implementation.
1) Runtime exploitation & blocking — vendors pushing real-time, but evidence varies Wiz’s runtime sensor for Windows and cloud-native workloads is positioned around real‑time threat detection, execution context, and blocking of suspicious behaviors across containers, VMs, and hybrid environments — framing runtime as a last line of defense with hybrid file integrity monitoring and automated responses. (wiz.io) Sysdig’s recent release notes focus on runtime vulnerability scanning, “in‑use” spotlighting of active vulnerabilities, and enhancements like cloud response actions in their threat detection feed, but explicit exploitability blocking is handled via policy/risk mechanisms rather than a singular “block here” narrative. (Sysdig Documentation)
This reinforces a practical buyer theme: raw runtime telemetry + reproducible blocking artifacts matter more than UI screenshots alone when evaluating exploitability claims.
2) VEX / OpenVEX tooling is still “experimental” in major scanners Trivy’s documentation still labels VEX support as experimental, outlining only basic filtering based on SBOM and VEX documents. (Trivy) Real community issues — like Trivy not suppressing multiple VEX statements for the same CVE when PURLs differ, or tools ignoring OpenVEX at ingestion time — highlight edge‑case gaps in practical suppression workflows. (GitHub)
For procurement, that means test vectors and compliance scripts should include VEX corner cases vendors rarely document.
3) Signing and attestation practices are evolving but not yet commodity Industry guidance (e.g., the emerging VeriSBOM research) emphasizes cryptographically verifiable SBOM assertions using zero‑knowledge proofs, selective disclosure, and trustless validation. Meanwhile, projects like Chainguard and cosign are promoting SBOM signing recipes and Rekor logs as artifacts, but the evidence of vendor support (signed DSSE envelopes + inclusion proofs) isn’t broadly published in recent release notes.
Why this matters right now
- Runtime claims without signed evidence or API artifacts leave buyers unable to prove exploitability coverage in audits.
- VEX tooling is improving but still fails on real-world suppression edge cases.
- Attestation infrastructure (DSSE + Rekor) is available; what’s missing is standardized published artifacts vendors can point to in procurement benchmarks.
You’re seeing exactly where procurement acceptance criteria can force conversion of vendor claims into verifiable artifacts rather than promises. This matters when evaluating CNAPP/CWPP platforms and asking vendors for reproducible evidence — not just UI screenshots or blog posts.
If you want, I can point you to specific RFCs, SBOM/VEX test cases, and trivy/Grype output examples showing these gaps in action.