VEX (Vulnerability Exploitability eXchange) is a form of security advisory whose single job is to state whether a specific product is actually affected by a specific known vulnerability. Where a vulnerability scanner says "this component contains CVE-2024-XXXX," a VEX document lets the software's producer respond authoritatively: "yes, and here is the fix" — or, just as importantly, "no, that code is present but not exploitable in our product, and here is why." VEX is designed to be machine-readable so it can be produced and consumed at scale, and it emerged from the SBOM work led by CISA and the former NTIA.
Why It Matters
The rise of the SBOM created a new problem: visibility without judgment. Once you know every component inside a product, automated scanners will happily match those components against vulnerability databases and generate a flood of alerts — many of which do not matter. A vulnerable function may never be called, the affected feature may be compiled out, or a mitigation may already neutralize the issue. Chasing those non-issues burns security and engineering time and, worse, trains teams to ignore alerts.
VEX is the answer to "the SBOM says we are affected, but are we really?" It lets a supplier communicate exploitability status directly and at machine speed, so a downstream consumer's tooling can automatically suppress the false positives and focus humans on the vulnerabilities that genuinely require action. In a world of transitive dependencies where a single component can appear in thousands of products, that suppression is the difference between an actionable queue and an unusable one.
How It Works
A VEX statement ties together three things: a product (identified precisely, often by a package identifier or SBOM reference), a vulnerability (usually a CVE), and a status describing the relationship between them. When the status is "not affected," the statement must also carry a justification — a standardized reason explaining why the vulnerability does not apply, so the claim is auditable rather than a bare assertion.
Because VEX is a concept rather than a single file format, it can be expressed in several standards. The three most common are CSAF 2.0 (the OASIS Common Security Advisory Framework, which includes a VEX profile), the CycloneDX VEX format (which can travel alongside or embedded with a CycloneDX SBOM), and OpenVEX (a deliberately minimal, standalone specification from the OpenSSF). All three encode the same core idea; they differ in verbosity and in how tightly they couple to an SBOM.
Key Parts of a VEX Statement
| Element | Purpose | Example values |
|---|---|---|
| Product | The exact artifact the statement is about | A package identifier or SBOM component reference |
| Vulnerability | The issue being addressed | A CVE identifier |
| Status | The affected relationship | not_affected, affected, fixed, under_investigation |
| Justification | Required when status is not affected | component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary, inline_mitigations_already_exist |
| Action statement | Guidance when status is affected | Upgrade instructions or workarounds |
The four status values are the heart of VEX. Not affected means no remediation is required and demands a justification. Affected means action is recommended and should carry guidance. Fixed means a given release already remediates the issue. Under investigation means the supplier does not yet know and is actively assessing.
Best Practices
- Always attach a justification to "not affected." An unexplained "not affected" is unverifiable. The standardized justifications turn a claim into an auditable one your consumers and auditors can trust.
- Generate VEX from evidence, not opinion. Base "not affected" statements on real analysis — reachability, configuration, or presence checks — so the claim reflects the product's actual behavior.
- Pair every VEX with the SBOM it references. VEX is only meaningful against a known component inventory; distribute the two together so consumers can line them up automatically.
- Keep statements current. Exploitability can change when you add a dependency or expose a new code path. Treat VEX as a living output of your pipeline, re-issued as the product evolves, not a one-time document.
- Prefer machine-readable exchange. The value of VEX is automated suppression at scale, so publish in a standard format your consumers' tools can ingest rather than in prose.
How Safeguard Helps
Safeguard produces VEX as a natural byproduct of analysis rather than a manual paperwork exercise. Its Software Composition Analysis determines which components carry known vulnerabilities, and reachability analysis then establishes whether the vulnerable code is actually invoked in your application — which is precisely the evidence a defensible "not affected" statement requires. That evidence flows into VEX documents keyed to the same components tracked in SBOM Studio, so your SBOM and your exploitability statements stay in lockstep.
On the consumption side, Griffin AI uses incoming VEX to automatically suppress vendor-cleared findings, collapsing a noisy scanner queue into the short list of vulnerabilities that genuinely warrant attention. The result is that VEX does what it was designed to do: keep your team working on real risk. For more supply chain concepts, see the concepts library.
Create a free account to generate and consume VEX from real analysis, or read the documentation for the supported formats.
Frequently Asked Questions
Is VEX the same thing as an SBOM? No. An SBOM is an inventory of the components in a product, while VEX is a statement about whether a specific vulnerability in one of those components actually affects the product. They are complementary: the SBOM tells you what is present, and VEX tells you what matters. VEX is far less useful without an SBOM to reference, and an SBOM without VEX tends to generate more alerts than it resolves.
What are the four VEX status values? The four statuses are not affected, affected, fixed, and under investigation. Not affected means no action is needed and requires a justification explaining why. Affected means remediation is recommended. Fixed means a particular release already resolves the issue. Under investigation means the supplier has not yet determined the impact and is assessing it.
Which VEX format should I use? The three mainstream options are CSAF 2.0, CycloneDX VEX, and OpenVEX. Choose CSAF if you already publish CSAF advisories, CycloneDX VEX if you standardize on CycloneDX SBOMs, and OpenVEX if you want the most lightweight, standalone option. What matters most is that the format is machine-readable and that your consumers can ingest it.
Does VEX let vendors hide vulnerabilities? Not credibly, because the standardized justifications make a "not affected" claim auditable. A consumer can review the stated reason, cross-check it against the SBOM and their own analysis, and reject statements that lack evidence. VEX increases transparency by forcing suppliers to say why something does not apply, rather than staying silent.