Vulnerability Exploitability Exchange (VEX)

What Is the Vulnerability Exploitability Exchange (VEX)?

The vulnerability exploitability exchange (VEX) is a standardized format for communicating whether a software product is actually affected by a known vulnerability. It lets a software producer state, in a machine-readable document, that a CVE present in a component is not exploitable in their product, or that it is and a fix is available. The goal is to separate vulnerabilities that exist on paper from the ones that pose real risk in a specific deployment.

VEX matters because modern applications inherit hundreds of open source components, and scanners flag every known CVE in those components regardless of whether the vulnerable code path is reachable. Security teams waste cycles triaging findings that were never exploitable. VEX gives them a structured signal to suppress the noise and focus remediation on issues that map to known exploited vulnerabilities and reachable code.

How VEX Works and What a VEX Document Contains

A VEX document captures the exploitability status of one or more vulnerabilities for a specific product or set of products. It is produced by whoever has the context to make the call, usually the software vendor, and consumed by downstream tools and customers.

At minimum, each VEX statement includes:

• Product identifier: The component or product the statement applies to, often expressed as a package URL or CPE.
• Vulnerability reference: The CVE or advisory ID the statement addresses.
• Status: Whether the product is affected, not affected, fixed, or still under investigation.
• Justification: When a product is not affected, a reason code explaining why, such as the vulnerable code not being present or not being reachable.

Tools ingest these statements and filter scan output accordingly, so a CVE marked not affected no longer surfaces as an actionable finding. This turns triage from a manual review into an automated, repeatable step.

VEX Status Types: Not Affected, Affected, Fixed, Under Investigation

Every VEX vulnerability statement carries one of four status values. Each tells the consumer something different about how to act.

The not affected status is where VEX delivers the most value, because it requires a justification. Common justifications include the vulnerable code not being present in the build, the code being present but not executed, or an existing control blocking the attack path. These justifications feed directly into vulnerability prioritization decisions.

VEX and SBOM: How They Work Together

A VEX SBOM pairing is the natural way to use both artifacts. An SBOM lists what is in your software, and VEX explains which of those components carry real risk.

An SBOM is an inventory of every component in a product, including transitive dependencies. On its own, it says nothing about exploitability. When a scanner cross-references an SBOM against a vulnerability database, it returns every CVE tied to every listed component, producing a large and largely theoretical finding list. VEX layers exploitability context on top, marking which CVEs actually matter. 

The SBOM provides the component map, and VEX annotates it with status. Major formats including OpenVEX, CycloneDX VEX, and CSAF VEX support this pairing, and several can embed VEX data alongside SBOM data.

How VEX Helps Reduce Vulnerability Noise in AppSec Programs

The practical payoff of VEX security is noise reduction at scale. The majority of CVEs flagged in a dependency scan are not reachable or not exploitable in the specific application.

When teams run software composition analysis across a large codebase, the raw output can run to thousands of findings. Without exploitability context, every one competes for attention, and analysts burn time confirming false positives. VEX automates that confirmation. A vendor-issued not affected statement, backed by a justification, lets the consuming team suppress the finding with an auditable record of why. The result is a shorter, higher-confidence backlog where remediation effort tracks actual risk.

FAQs

Is VEX a replacement for an SBOM or a complement to it?

VEX complements an SBOM. The SBOM inventories components, while VEX states whether known vulnerabilities in those components are exploitable. Used together, they give a complete picture of what is present and what poses real risk.

Who is responsible for issuing a VEX document, the vendor or the consumer?

Usually the software producer or vendor, since they have the deepest context on whether a vulnerability is reachable in their product. Consumers can author internal VEX statements but typically rely on vendor-issued ones.

How does VEX reduce false positives in SCA scanning results?

VEX marks vulnerabilities as not affected with a documented justification, letting scanners suppress those findings automatically. This filters out CVEs that exist in components but cannot be exploited, shrinking the triage backlog.

Which VEX formats are currently supported by major tools?

The three most common formats are OpenVEX, CycloneDX VEX, and CSAF VEX, with SPDX 3.0 also carrying VEX data. Scanners such as Trivy, Grype, and Anchore consume one or more of these.

Is VEX required for any compliance frameworks today?

No framework currently mandates VEX. It is referenced in CISA and NTIA software supply chain guidance, and US federal SBOM expectations became risk-based in early 2026, leaving VEX recommended rather than required.