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.

![Image](https://www.datocms-assets.com/75231/1728918689-sensor-attack.gif)

![Image](https://cdn.prod.website-files.com/681a1c8e5b6ebfc0f8529533/689cbeac169e6f38021203c0_monitor-cost.png)

![Image](https://www.securecodebox.io/assets/images/2023-09-15-depencytrack-projects-6458c7f735d045c0780725a63f52be21.png)

![Image](https://opengraph.githubassets.com/0edbec120b6b051cfc92d3f1ef68e3779e92b8b5c3d86b048b2a334b3492284a/aquasecurity/trivy/discussions/10094)

**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][1])
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][2])

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][3])
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][4])

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.

[1]: https://www.wiz.io/blog/wiz-runtime-sensor-for-your-windows-environment?utm_source=chatgpt.com "Cloud-native Security for your Windows environment"
[2]: https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/?utm_source=chatgpt.com "SaaS: Sysdig Secure Release Notes"
[3]: https://trivy.dev/docs/v0.51/supply-chain/vex/?utm_source=chatgpt.com "VEX"
[4]: https://github.com/aquasecurity/trivy/discussions/7885?utm_source=chatgpt.com "CycloneDX VEX: Trivy fails to suppress all findings when ..."