VEX (Vulnerability Exploitability eXchange) is a companion to SBOMs that communicates whether a known vulnerability in a software component is actually exploitable in a specific product. VEX uses four status codes — Not Affected, Affected, Fixed, Under Investigation — to help organizations prioritize remediation and prove compliance.
VEX exists because SBOMs alone create a misleading picture. An SBOM tells you that your application includes a component with a known CVE. It does not tell you whether that CVE is actually reachable in your specific deployment. Without VEX, every CVE in your dependency tree looks equally urgent — and most of them are not.
The concept originated from work by NTIA (National Telecommunications and Information Administration) and CISA (Cybersecurity and Infrastructure Security Agency) to address a core problem: organizations receiving SBOMs were drowning in vulnerability noise with no way to distinguish real risk from theoretical exposure (NTIA VEX Working Group, 2021).
Every VEX document assigns one of four status codes to a specific vulnerability-product pair. Each code carries a distinct operational meaning.
The vulnerability exists in the component, but it is not exploitable in this product. The vulnerable function is never called, the vulnerable code path is unreachable, or the deployment configuration prevents exploitation. This is the most valuable status for noise reduction — it tells your security team and your auditors to move on.
Example: CVE-2024-1234 affects library-x version 3.2.1. Your application imports library-x but never invokes the vulnerable parseXML() function. VEX status: Not Affected.
The vulnerability is exploitable in this product and requires action. The vulnerable code path is reachable and the conditions for exploitation exist in your deployment. This status triggers remediation workflows.
The vulnerability was previously exploitable but has been remediated. The fix is deployed and the product is no longer at risk. This status provides audit evidence that your team identified and resolved the issue.
The vendor or development team is still assessing whether the vulnerability is exploitable in this product. This is a temporary status — it acknowledges the CVE and signals that analysis is in progress, rather than leaving auditors guessing.
VEX moved from optional best practice to near-mandatory compliance artifact across three regulatory vectors.
VEX is not a single file format. It is a concept implemented across three standards, each with distinct strengths.
| Format | Maintainer | Strengths | Best For |
|---|---|---|---|
| CycloneDX VEX | OWASP | Native SBOM integration, JSON/XML, lightweight | Organizations already using CycloneDX SBOMs |
| CSAF VEX | OASIS | Most mature VEX profile, rich advisory context | Enterprise security advisory workflows |
| SPDX VEX | Linux Foundation | License + vulnerability in one document | Open source compliance-heavy environments |
CycloneDX embeds VEX directly into the SBOM document. CSAF (Common Security Advisory Framework) treats VEX as a standalone advisory profile, which is useful when you need to distribute exploitability information separately from the SBOM. SPDX supports VEX through its security vulnerability extension.
In practice, most organizations choose the format that matches their existing SBOM toolchain. The exploitability information is the same regardless of container format.
Producing a VEX document by hand is slow and does not scale. For each CVE in your dependency tree, someone needs to determine whether the vulnerable function is actually called in your product. With enterprise applications pulling in hundreds of transitive dependencies — 77% of the dependency tree is indirect packages your team never explicitly chose (Forrester Research, 2024) — manual VEX authoring becomes a full-time job that never finishes.
This is the same root cause behind the 252-day average time to remediate a known vulnerability (Veracode State of Software Security, 2024). If your team cannot determine exploitability at scale, they cannot prioritize at scale.
Pixee’s codebase-aware exploitability analysis (Deep Research Agents + Coding Agents) does the investigative work that manual VEX authoring cannot match at scale. Important: Pixee classifies exploitability internally — it does not export VEX documents. Teams use Pixee’s analysis as the evidence basis for authoring VEX documents via their preferred tooling.
Triage automation produces exploitability classifications that map to VEX status codes. Pixee analyzes whether vulnerable functions in your dependency tree are actually invoked by your application code. When a CVE’s vulnerable code path is unreachable, Pixee classifies it as “Not Affected” — backed by evidence your auditors can verify. This analysis achieves a 95% false positive reduction across findings from 10+ scanner tools (Pixee Platform Data, 2025), which means 95% of the noise that buries your team gets resolved with a defensible classification instead of manual investigation.
Remediation automation handles confirmed-exploitable findings. When Pixee’s analysis confirms a vulnerability is exploitable, it generates a context-aware fix — a dependency version bump, a function replacement, or a configuration change — and delivers it as a pull request matching your codebase conventions. Developers merge 76% of these fixes (Pixee Platform Data, 2025 — measured across 100k+ PRs). Once merged, teams can update their VEX document to “Fixed” status with full audit provenance: git commit, test results, and the analysis that triggered remediation.
Your auditor asks about CVE-2024-1234 in jackson-databind. Instead of spending hours tracing call graphs manually, you run Pixee’s exploitability analysis. For the “Not Affected” finding, Pixee provides the justification (“vulnerable deserialization path not reachable”) and evidence. Your team authors the VEX document using that evidence. For CVE-2024-5678 that was exploitable and fixed, the VEX document your team maintains shows status “Fixed,” with a link to the merged PR and passing CI results from Pixee’s fix.
This is the difference between responding to an audit with “we’re working on it” and responding with machine-verifiable evidence.
An SBOM lists the components in your software — what libraries, what versions. VEX answers the follow-up question: are the known vulnerabilities in those components actually exploitable in your product? Think of the SBOM as the ingredient list and VEX as the safety assessment. You need both. The SBOM without VEX tells you a vulnerability exists; VEX tells you whether it matters. CISA recommends pairing them for federal software compliance (CISA, “VEX Use Cases,” 2022).
No. VEX communicates exploitability status — it does not discover vulnerabilities. You still need SCA scanners (Snyk, Checkmarx, Semgrep, etc.) to identify CVEs in your dependency tree. VEX sits downstream: after your scanner flags a CVE, the VEX document records whether that CVE is exploitable, not exploitable, fixed, or under investigation. Pixee integrates with 10+ scanner tools to automate this determination through reachability analysis rather than manual triage.
Start by identifying your highest-risk applications — the ones auditors ask about, the ones facing regulatory deadlines. Run reachability analysis against their dependency trees to determine which CVEs are actually exploitable. That analysis output maps directly to VEX status codes. If you are doing this manually, expect it to take weeks per application. Automated tools like Pixee can generate exploitability determinations at scale, producing VEX-ready data as a byproduct of triage automation.
Software Supply Chain Security
The complete guide to securing your software supply chain — from SBOMs to remediation.
Related GuideReachability Analysis: Why Most Dependency CVEs Don’t Matter
How reachability analysis identifies which vulnerabilities are actually exploitable in your code.
Related GuideWhat is SBOM? The Complete Guide to Software Bills of Materials
Everything you need to know about SBOMs — the foundation VEX builds on.
Pixee generates defensible VEX status determinations automatically — Not Affected, Fixed, or Affected with a PR — across your full dependency tree.
The briefing security leaders actually read. CVEs, tooling shifts, and remediation trends — distilled into 5 minutes every week.
Join security leaders who start their week with AppSec Weekly. Free, 5 minutes, no fluff.
First briefing drops this week. Check your inbox.
Weekly only. No spam. Unsubscribe anytime.
