VEX: filtering vulnerability noise with context
Actualizado: 2026-05-03
Anyone who went through the Log4Shell nightmare in December 2021 understands why VEX exists. In those days, any Java application had an associated critical CVE, and a huge number of them weren’t vulnerable at all: they didn’t expose the affected class, didn’t process external inputs with the library, or simply didn’t load the vulnerable piece at runtime. But without a structured way to communicate this, every vendor answered questions over and over, and every customer re-evaluated the same risk from scratch. Three years later, the industry has absorbed that lesson and the Vulnerability Exploitability eXchange (VEX) is taking shape as a standard mechanism to filter that noise.
This post explains what VEX is, when it adds value in a supply chain pipeline, what formats exist, and what mistakes repeat in the adoptions I’ve seen. For broader software supply chain context, the article on Sigstore and registry adoption provides the integrity layer that complements VEX.
Key takeaways
- VEX is a structured document communicating the real exploitability of a CVE in the context of a specific product.
- The four VEX statuses are: not affected, affected, fixed, under investigation.
- The main formats are CycloneDX (VEX embedded in SBOM), CSAF VEX, and OpenVEX (lighter weight).
- VEX does not replace the SBOM; it complements it by adding the impact context the SBOM lacks.
- The most common mistake is issuing VEX without evidence: “not affected” without justification is worthless to the recipient.
What VEX is and what problem it solves
An SBOM lists the components of a software artifact. When a vulnerability database (NVD, GHSA) reports a CVE in one of those components, the dependency scanner flags it as vulnerable. The problem is that flag doesn’t distinguish between “the component is included and the vulnerability is exploitable in this context” and “the component is included but the vulnerable code never executes, or the attack vector doesn’t apply to how we use it.”
VEX is the mechanism that communicates that distinction. A VEX document, issued by the product vendor, explicitly states the exploitability status of a specific CVE in that specific product. The receiver (the customer, the scanner, the vulnerability management platform) can use that information to suppress false-positive alerts or prioritize remediation more precisely.
The useful analogy is an attestation: it doesn’t remove the CVE from the database, but it certifies that for this product, in this context, the CVE is not exploitable in the way the generic description describes.
The four VEX statuses
The VEX specification defines four possible statuses for a component in relation to a CVE:
- Not affected: the product includes the component but is not vulnerable. Requires justification (standard categories are: component not present, vulnerable code not present, inline mitigations already exist, vulnerable code cannot be controlled by adversary).
- Affected: the product is vulnerable to the CVE. May include additional information on the attack vector or exploitability conditions.
- Fixed: the CVE has been remediated in the specified product version.
- Under investigation: the vendor is evaluating the CVE’s impact; transitional status indicating response is in progress.
The justification category for “not affected” is the most important part in practice. A “not affected” without justification provides no more confidence than absence of information, because the receiver can’t know whether the vendor actually analyzed the impact or simply marked it without investigating.
Formats: CycloneDX, CSAF, and OpenVEX
There are three main formats for issuing VEX:
CycloneDX with embedded VEX. CycloneDX is an SBOM format that includes native VEX support as part of the same document or as a separate vulnerability document (BOM-Link). It’s the most integrated with the tooling ecosystem already generating CycloneDX SBOMs (Syft, Trivy, CDXGEN). If you already have a CycloneDX SBOM pipeline, this is the lowest-friction path.
CSAF VEX. CSAF (Common Security Advisory Framework) is the OASIS standard for security advisories, and its VEX profile is most appropriate for organizations with formal vulnerability disclosure processes. It’s the preferred format for large enterprise software manufacturers and integrates best with vendor vulnerability management platforms. It has more structure and overhead than the other two.
OpenVEX. A lighter format, driven by Chainguard and adopted by the SLSA project. In JSON-LD, it’s the easiest to generate and consume programmatically. It doesn’t yet have the tooling ecosystem of the other two, but has the most compatibility with modern software integrity chains (Sigstore, cosign, SLSA).
How it fits in a supply chain pipeline
VEX integrates best when an SBOM generation flow is already established. The typical pipeline with VEX has three phases:
- SBOM generation: in the build process, using Syft, Trivy, or the language-specific tool. The SBOM describes the exact components of the artifact.
- Vulnerability scanning: the SBOM is passed to a scanner (Grype, Trivy, Dependency-Track) that crosses components with vulnerability databases and produces a CVE list.
- VEX application: the scanner or management platform applies available VEX documents to suppress false positives or update remediated vulnerability status.
The most missing step is the internal VEX generation process: who determines each CVE’s status, how the justification is documented, at what cadence it’s reviewed. Without that internal process, VEX isn’t generated or is generated without rigor.
Common mistakes in adoption
Mistakes I’ve seen repeating in organizations starting with VEX:
Issuing VEX without evidence. “Not affected” without categorized justification and without evidence someone actually analyzed the impact is worse than issuing nothing, because it gives false reassurance. The justification doesn’t have to be elaborate, but it must exist and be specific.
Treating VEX as a solution to noise rather than as a discipline. VEX reduces false-positive noise long-term, but requires upfront investment: analyzing each relevant CVE, categorizing, documenting. Organizations expecting VEX to solve the vulnerability management problem without that investment are disappointed.
No update process. A VEX issued as “not affected” can become stale if component usage in the product changes or a previously unconsidered attack vector is discovered. Without periodic review, accumulated VEX is a trust debt.
Confusing automated VEX generation with quality VEX. Some tools generate VEX automatically by inferring status from static analysis. It can be a good starting point, but automatically generated VEX without human review has the reliability of the analysis producing it, which often has false positives and negatives.
My read
VEX is the missing piece between the SBOM and the remediation decision. The SBOM says what’s there; VEX says what matters in this context. Without VEX, every CVE in the SBOM demands investigation. With well-issued VEX, the investigation is already done and documented by whoever can do it best: the component or product vendor.
Adoption in CI/CD pipelines is advancing, but the bottleneck is the human process of analysis and justification. Teams that handle it best are those treating VEX as part of vulnerability management, not as an artifact automatically generated at the end of the build. The quality of VEX is the quality of the analysis behind it.
