VEX (Vulnerability Exploitability eXchange)
Vendor statements of which CVEs actually affect which products.
What is VEX?
VEX — Vulnerability Exploitability eXchange — is a machine-readable statement issued by a software producer that says, for each CVE affecting a component it ships, whether the product is actually affected, not affected, fixed, or under investigation, and why.
It is the companion document to an SBOM. The SBOM says “this product contains lodash 4.17.20.” VEX says “CVE-2021-23337 is present in that dependency but our product is not affected because the vulnerable function is never called in our configuration.” Standard formats include CycloneDX VEX, CSAF 2.0, and OpenVEX.
How it works
A VEX document is a list of statements, each with a CVE, a product identifier, a status, and — crucially — a justification:
- 01
Status
affected,not_affected,fixed, orunder_investigation. Each status has a precise meaning in the spec. - 02
Justification (for `not_affected`)
Standard enum values: component_not_present, vulnerable_code_not_present, vulnerable_code_cannot_be_controlled_by_adversary, vulnerable_code_not_in_execute_path, inline_mitigations_already_exist. Regulators expect one of these rather than a free-text excuse.
- 03
Signed and distributed
VEX documents are typically signed and published alongside SBOM and provenance — either on a vendor portal, via a standard endpoint (CSAF 2.0 defines one), or embedded in OCI-compliant registries next to the artifact.
Why it matters
Once consumers start scanning vendor SBOMs, every open CVE in every shipped dependency turns into a customer ticket. Most of those CVEs are not exploitable in the specific product configuration — but without a machine-readable answer, the vendor's support team fields the same email thousands of times.
VEX converts that thread into a signed document. The consumer's scanner automatically suppresses the noise, the vendor's support load drops, and both sides can point to a durable audit artifact. This is the only mechanism that makes SBOM adoption sustainable at scale.
What value it adds
Cross-organization CVE noise reduction
Vendor-signed “not affected” statements automatically suppress findings in consumer scanners — the same CVE is not re-triaged across every customer.
Lower support load for vendors
Instead of answering the same CVE question in a thousand tickets, publish one VEX document and let consumer tooling read it.
Defensible audit trail
Every “not affected” carries a spec-defined justification — exactly the kind of evidence a regulator or enterprise customer expects to see.
Reachability maps cleanly to VEX
If your reachability analyzer proves the vulnerable function is unreachable, the matching VEX statement (vulnerable_code_not_in_execute_path) generates itself.
Unblocks SBOM adoption
Without VEX, publishing SBOMs floods customers with false positives. With VEX, both documents are useful together — which is why regulators now co-mandate them.
How Safeguard uses it
Safeguard generates VEX statements automatically from reachability analysis output, stores them next to the relevant SBOM, and publishes them through the SBOM Studio distribution surface.
Publish VEX next to every SBOM.
Point Safeguard at a product. Auto-generate VEX statements from reachability, signed and distributable.
Self-healing security runs on Safeguard.
Your first fix PR is minutes away.
No sales call required, even your agent can complete the purchase over MCP.