How Vulnerability Exploitability Exchange (VEX) Helps AppSec Teams Cut False-Positive Noise

Key Takeaways

• Most scanner findings are not exploitable: The vast majority of vulnerability alerts flag the presence of a component, not its actual risk in your environment. VEX provides the machine-readable context to separate the two.
• VEX communicates exploitability status: A VEX document is a structured advisory that tells consumers whether a known vulnerability is Not Affected, Affected, Fixed, or Under Investigation in a specific product configuration.
• VEX and SBOM are companions: An SBOM lists what is in your software. VEX tells you whether any of it is actually dangerous right now.
• Operationalizing VEX cuts triage time dramatically: Teams that integrate VEX into their vulnerability management workflows can suppress 80-90% of non-actionable findings before they reach a developer queue.
• Exploitability context is the path to clearing backlogs: Combining VEX with reachability analysis and code-to-runtime context gives AppSec teams the intelligence to prioritize remediation based on actual business risk.

---

Vulnerability exploitation just overtook credential abuse as the number one cause of data breaches for the first time in the Verizon DBIR’s history. 

The volume problem behind that shift is staggering. CVE submissions to NIST’s National Vulnerability Database grew 263% between 2020 and 2025, with Q1 2026 running a third higher still. Every new disclosure triggers alerts across scanners, dashboards, and developer queues. 

But only 5.5% of all reported vulnerabilities are ever exploited in the wild. The rest is noise that burns engineering hours, buries real risk, and inflates backlogs that never shrink.

The teams cutting through this are doing something different. They are filtering findings through exploitability context before anything reaches a developer by asking whether a vulnerability is actually reachable, actually dangerous, and actually worth fixing in their specific environment. 

The mechanism that makes this possible at scale is the Vulnerability Exploitability Exchange, or VEX.

VEX helps AppSec teams separate exploitable risk from noise. That’s why teams need to understand how VEX works, what each status means, and how to use exploitability intelligence to prioritize remediation. 

The False Positive Problem in Vulnerability Management

Security scanners are designed to catch as much as possible, which often comes at the cost of precision. 

Static application security testing (SAST), software composition analysis (SCA), and infrastructure-as-code (IaC) tools flag every vulnerable library or code pattern they find, regardless of whether the vulnerability is reachable, exploitable, or even present in the execution path. The goal is zero missed findings, but in reality, this leads to tens of thousands of alerts that overwhelm the teams responsible for acting on them.

The math makes vulnerability management unsustainable at scale. Only 26% of vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog were fully remediated in 2025, down from 38% the year before. Median time to full patching climbed to 43 days. 

Organizations fall behind when every scanner finding carries the same urgency, with no clear way to separate real risk from noise.

AI-assisted development is compounding the problem. Georgetown CSET found that nearly half of AI-generated code samples contained bugs that could lead to exploitable vulnerabilities. As AI coding assistants accelerate the rate of code changes, the volume of findings entering the backlog grows faster than any team can triage manually. The creation-remediation gap is widening, and adding more scanners only makes it worse.

AppSec teams need exploitability context that shows, programmatically, whether a vulnerability poses real risk in their specific environment.

What Is VEX (Vulnerability Exploitability Exchange)?

Vulnerability Exploitability Exchange is a machine-readable advisory format designed to communicate whether a known vulnerability is actually exploitable in a specific product configuration. It answers the question that scanners cannot: does this CVE affect my software, or is it just noise?

VEX originated from the same NTIA multistakeholder group that formalized software bill of materials (SBOM) recommendations. The two are designed to work together. 

An SBOM is a static inventory of what components are in a software product. A VEX document is its dynamic companion, a structured attestation from the software producer that clarifies the risk status of those components as new vulnerabilities emerge. The SBOM tells you what you have. VEX tells you whether any of it is dangerous right now.

As defined by CISA, a valid VEX document contains four data elements: 

1. Document metadata (author, timestamp, version)
2. Product details (what software is covered)
3. Vulnerability details (which CVE is being addressed)
4. Product status (the exploitability determination). 

That last element, product status, is the core of the VEX assertion and what makes automated triage possible.

In mature implementations, VEX data can reduce the manual triage burden by 80 to 90 percent by programmatically suppressing verified non-exploitable findings before they ever reach a developer queue.

How VEX Works: The Four Status Statements

Every VEX assertion is associated with one of four standardized statuses. Each tells downstream tools and security teams how to categorize a finding based on its actual risk, not its theoretical severity.

Not Affected

The primary driver of noise reduction. A Not Affected status means the vulnerable component is present in the software, but the product is not exploitable in its specific context. For AppSec teams, this is a definitive instruction to suppress the finding and move on.

This status is especially valuable during high-profile disclosures like Log4j, where thousands of products contained the library but only a fraction used the specific functions required for exploitation. 

To ensure these assertions are trustworthy and machine-readable, CISA has formalized five justification codes that explain the reasoning behind them. Two of the most common include the vulnerable code is not in the execution path (the application never calls the affected function), or inline mitigations already exist (built-in protections prevent exploitation regardless).

Affected

An Affected status confirms that the vulnerability is exploitable in this product’s configuration. Unlike a generic scanner alert, this represents a validated risk that requires action. 

Affected statements typically include remediation guidance, such as a recommended version upgrade, a configuration change, or a temporary workaround.

Fixed

Fixed identifies the specific product versions where a previously Affected vulnerability has been patched. 

This enables automated tools to verify that remediation was applied correctly and to close out historical findings in the risk register. It also provides version-level tracking across the software development lifecycle.

Under Investigation

A transitional status indicating the producer is aware of the vulnerability and actively analyzing its impact. 

For consumers, this prevents the panic of an unacknowledged CVE while signaling that a definitive Not Affected or Affected statement is coming. It communicates transparency during high-pressure disclosure windows.

Integrating VEX Into Your AppSec Workflow

VEX delivers value only when it moves from concept to operational practice. Embedding it into an AppSec program requires a progression across four stages:

1. Map your full inventory: Start with an enriched software bill of materials that goes beyond listing dependencies. Use deep code analysis to understand which components are actually called, which are exposed to the internet, and which sit behind existing controls. Without this foundation, there is no way to determine exploitability programmatically.
2. Automate triage with VEX data: Ingest VEX statements from suppliers (Microsoft, Red Hat, and others publish them for their products) alongside internally generated assertions from your own reachability analysis. When a component carries a Not Affected status with a valid justification, suppress the corresponding alert before it reaches a developer dashboard.
3. Embed checks in developer workflows: Wire VEX lookups into pull request reviews and build pipelines. When a developer introduces a new open source dependency with a known CVE, the pipeline should check the exploitability status before raising a flag. This prevents security debt from accumulating at the point of commit.
4. Monitor continuously: VEX statuses change. An Under Investigation finding can shift to Affected when new research emerges. The workflow must detect status changes automatically, re-prioritize affected findings, and notify the responsible code owners. Vulnerability prioritization is not a one-time exercise. It is a continuous feedback loop between inventory, exploitability intelligence, and remediation.

Several machine-readable formats carry VEX data today, including CSAF 2.0, OpenVEX, CycloneDX, and SPDX 3.0. Each has different strengths. CSAF is the most mature for large vendor advisories, OpenVEX is lightweight and ideal for open source projects, and CycloneDX embeds VEX directly within the SBOM itself. The right choice depends on your toolchain and ecosystem.

Exploitability Context Is the New Foundation of AppSec

VEX gives AppSec teams a standardized language for the question that matters most: does this vulnerability actually affect us? 

When that question is answered programmatically, through machine-readable attestations tied to real architecture and runtime context, the entire vulnerability management model changes. Backlogs shrink, developers fix what matters, and vulnerability prioritization shifts from CVSS scores and gut instinct to evidence-based decisions grounded in how the software actually runs.

Apiiro’s Software Graph and Risk Graph support these processes by mapping the full software architecture from code to runtime and correlating findings with reachability, business impact, and existing mitigations to determine which vulnerabilities pose actual risks. Agentic capabilities powered by AutoFix, AutoGovern, and AutoManage automate remediation, enforce security policies, and manage the risk lifecycle throughout the SDLC, enabling AppSec teams to operate at the same velocity as the developers they support.

Stop triaging findings your team will never need to fix. Schedule a demo today to see how Apiiro turns exploitability context into automated action. 

FAQs

What is Vulnerability Exploitability Exchange (VEX), and who should use it?

VEX is a machine-readable advisory format that communicates whether a known vulnerability is exploitable in a specific software product. Software producers use it to inform customers about the actual risk status. Enterprise AppSec teams use it to automate triage and suppress non-exploitable findings across their application portfolios.

How does VEX reduce false positives in vulnerability scanning?

Standard scanners flag every vulnerability associated with a component, regardless of whether it is reachable or exploitable. VEX provides a structured attestation proving the vulnerable code is not executed, not present, or otherwise mitigated. Security platforms ingest these attestations and programmatically suppress non-actionable findings, cutting noise significantly.

What is the difference between VEX and SBOM?

An SBOM is a static inventory of components in a software product, typically generated at build time. VEX is a dynamic companion that clarifies the exploitability status of those components as new vulnerabilities are disclosed. The SBOM lists ingredients. VEX tells you whether any of those ingredients are dangerous in your specific configuration.

Which vulnerability scanning and AppSec tools support VEX?

Support is growing across the ecosystem. Microsoft publishes CSAF-based VEX for Azure Linux. Red Hat issues VEX statements for its product portfolio. CycloneDX generators, the Go toolchain, and Docker Scout have integrated VEX support. Leading ASPM platforms now ingest VEX data to unify signals and automate triage across native and third-party scanners.

How do AppSec teams use VEX to prioritize remediation effectively?

Teams use VEX to separate the small percentage of reachable, exploitable vulnerabilities from thousands of non-actionable scanner findings. By combining VEX assertions with reachability analysis and business context, they focus engineering resources on fixing Affected vulnerabilities that pose a genuine risk to their most critical applications.