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 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: the vulnerable component isn't present in the build, the component is present but the vulnerable code isn't, the vulnerable code is present but never reached during execution, the vulnerable code can't be controlled by an adversary, or an inline mitigation already neutralizes the threat. 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.

VEX is a concept before it is a format. In practice it is implemented across three specifications: CSAF VEX, CycloneDX VEX, and OpenVEX, each with its own encoding, tooling ecosystem, and design philosophy. CSAF, developed by OASIS, is the most comprehensive and suits organizations distributing formal security advisories. CycloneDX embeds VEX data directly into its SBOM structure, keeping component inventory and exploitability information together. OpenVEX is the most minimal of the three, designed to be lightweight and embeddable across formats. All three share the same fundamental data model: product, vulnerability, status and justification, which means the underlying information translates across them, even if toolchain interoperability remains imperfect in practice.

VEX in DevGuard

DevGuard treats VEX as a built-in part of the vulnerability workflow: you record a status and justification on a finding during triage, and DevGuard stores it as machine-readable VEX that can be exported or consumed from upstream suppliers. For the hands-on steps, see the how-to guide on generating VEX documents.

Have feedback? We want to hear from you!

Fields marked with * are required