What is a VEX Report
VEX (Vulnerability Exploitability eXchange) is a standard for communicating whether a known vulnerability actually affects a specific product. This page explains the problem it solves, the design of the standard, and the formats it is implemented in.
Where does VEX originate from
Modern software depends on layers of third-party libraries, creating a real challenge around understanding what components are in use and what risks they carry. The industry has developed solid infrastructure for this: Software Bills of Materials (SBOMs) inventory a product's components, and Software Composition Analysis (SCA) tools cross-reference those inventories against vulnerability databases like the NVD or OSV, surfacing any component version with a known CVE.
But this pipeline has a fundamental limitation: it answers the question of what vulnerabilities exist in the components your product uses, not whether those vulnerabilities actually affect your product. A CVE describes a flaw in a library in the abstract. Whether that flaw poses real risk in a specific product depends on factors the database cannot know: Is the vulnerable code included in the final build? Is it ever reached during execution? Does the surrounding environment neutralize the threat?
The consequence is a high rate of false positives. Findings that look alarming often turn out not to apply — the vulnerable function is stripped from the production artifact, the affected code path is never enabled, the exploit requires network access to a service that isn't exposed. At scale, security teams work through hundreds of such findings per release cycle, most leading nowhere. The noise erodes trust in tooling and makes it structurally difficult to act on the vulnerabilities that genuinely matter.
VEX — short for Vulnerability Exploitability eXchange — emerged as a direct response to this gap. The concept grew out of the NTIA's Software Component Transparency working group around 2020 and is now stewarded by CISA as part of its broader SBOM effort. Where the existing ecosystem tells you what vulnerabilities are present in a product's components, VEX provides a standardized way to communicate whether those vulnerabilities actually affect a specific product — giving vendors and maintainers a format to share the analysis they already perform internally, but have historically had no standard way to distribute.
What is the VEX standard
A VEX document is a machine-readable assertion about the relationship between a specific product and a specific vulnerability. Where a CVE entry describes a flaw in a library, a VEX statement answers a different question: does that flaw apply to this product, in this version, as shipped? The distinction matters because the same vulnerability might affect one vendor's product while being completely irrelevant to another's, even when both include the same underlying library. VEX gives vendors a standardized way to make that context explicit, rather than leaving each consumer to re-derive the same analysis independently.
The core of a VEX statement is a status, one of four values that together cover the complete space of how a product can relate to a known vulnerability. A product might not be affected at all, might be affected and require action, might already have a fix in place, or might still be under investigation. These are not arbitrary categories; they map directly to the real states a security team works through when a new CVE lands. Under investigation is where every triage starts. Not affected, affected, and fixed are where it ends. The design reflects the actual workflow of vulnerability response, not an abstract taxonomy.
The four statuses are:
| Status | Meaning |
|---|---|
| Under investigation | You are still analyzing whether the vulnerability affects the product. |
| Not affected | The vulnerability does not affect the product. Requires a justification. |
| Affected | The vulnerability affects the product and action is warranted. |
| Fixed | The vulnerability has been remediated in this version. |
The most carefully considered part of the standard is what happens when a vendor claims a product is not affected. That status requires a justification, a machine-readable explanation of why the product isn't vulnerable. The standard defines five valid justification labels:
| Justification | The claim it makes |
|---|---|
| Component not present | The vulnerable component isn't in the shipped product at all. |
| Vulnerable code not present | The component ships, but the vulnerable code was excluded. |
| Vulnerable code not in execute path | The vulnerable code is present but never executed. |
| Vulnerable code cannot be controlled by adversary | It executes, but no attacker-controlled input reaches it. |
| Inline mitigations already exist | A compensating control neutralizes the exploit. |
This requirement exists because a not-affected claim is the hardest assertion to verify from the outside. Without a justification, it is an ungrounded declaration. With one, it becomes something that can be audited, challenged, and trusted. For which one to choose in practice, see Choose a Mechanical Justification.
VEX is a concept before it is a format. In practice it is implemented across three specifications, each with its own encoding, tooling ecosystem, and design philosophy:
| Format | Design | Best suited for |
|---|---|---|
| CSAF VEX (OASIS) | Product-centric, models full dependency relationships | Formal advisories, regulated environments, per-path decisions |
| CycloneDX VEX | Component-centric, embedded in the SBOM structure | Keeping inventory and exploitability together; broad scanner support |
| OpenVEX | Minimal and embeddable | Lightweight exchange, attaching statements to artifacts |
All three share the same fundamental data model — product, vulnerability, status, justification — so the underlying information translates across them, even if toolchain interoperability remains imperfect in practice. How the formats differ concretely is covered in CSAF & VEX Standards.
VEX in DevGuard
DevGuard treats VEX as a built-in part of the vulnerability workflow rather than a separate reporting step. When you assess a finding during triage, DevGuard records the status and justification as an event and stores it as machine-readable VEX.
Two properties of DevGuard's model are worth knowing, because they go beyond what the formats themselves express:
- Decisions are per dependency path. The same vulnerable library can enter your product through several routes. DevGuard tracks each one separately, so you can dismiss the route where the vulnerable function is never called without silencing the others. Only CSAF can carry this distinction on export.
- Decisions can be automated. Rather than assessing findings one at a time, a VEX rule pairs a CEL expression with a status and justification, and applies it to every match — now and in future scans.
DevGuard both publishes and consumes VEX: your assessments become CycloneDX VEX, OpenVEX and CSAF documents for your consumers, and your suppliers' documents become rules in your own repository. See Working with VEX in DevGuard for the complete workflow.
Related Documentation
- Working with VEX in DevGuard — the practical workflow, end to end
- CSAF & VEX Standards — how the three formats are structured and where they differ
- Choose a Mechanical Justification — applying the five justifications correctly
- VEX Rules — automate VEX decisions across matching vulnerabilities
- Vulnerability Lifecycle — how VEX states map onto the states a vulnerability moves through
- Reduce False Positives — the false-positive problem VEX is designed to address