VEX Explained: How Vulnerability Exploitability Exchange Cuts Through Alert Noise

If you've ever run a vulnerability scanner against a container image and received hundreds of CVE alerts — most of which don't actually affect your application — you understand the problem that VEX was designed to solve. The Vulnerability Exploitability eXchange (VEX) is a mechanism for software producers to communicate to their consumers which known vulnerabilities in their components are actually exploitable in the context of their product.

In a world drowning in vulnerability alerts, VEX is the signal in the noise.

The Alert Fatigue Problem

Consider a typical modern application. It runs in a container based on a Debian image, which contains hundreds of system packages. The application itself has dozens of direct dependencies, each with their own transitive dependencies. A vulnerability scan of this application might return 200+ CVEs.

But how many of those CVEs actually matter? A vulnerability in a library function your application never calls isn't a risk. A CVE in a tool that's present in the container image but never executed at runtime isn't exploitable. A vulnerability that requires a specific configuration you don't use is irrelevant.

Without VEX, every consumer of your software has to independently analyze every reported vulnerability to determine if it's actually exploitable in their context. This is wasteful, error-prone, and doesn't scale.

What VEX Is

VEX is a form of security advisory that allows a software supplier to assert the status of a vulnerability with respect to their specific product. The core concept is simple: for each combination of product and vulnerability, the supplier states one of four statuses:

• Not Affected: The product is not affected by the vulnerability. The supplier provides a justification (e.g., the vulnerable code is not present, the vulnerable function is never called, the vulnerable configuration is not used).

• Affected: The product is affected by the vulnerability. The supplier may provide remediation guidance or an action statement.

• Fixed: The vulnerability was previously present but has been remediated in this version.

• Under Investigation: The supplier is still analyzing whether the product is affected.

Each status includes justification or supporting detail, so consumers can understand the reasoning behind the assessment rather than taking it on blind faith.

VEX Formats

As of mid-2022, VEX existed in two primary formats:

CSAF VEX

The Common Security Advisory Framework (CSAF) 2.0, published by OASIS, includes a VEX profile. CSAF VEX documents are JSON files that follow the CSAF schema with specific requirements for the VEX use case. This is the more mature and formally specified format.

A CSAF VEX document includes:

• Document metadata (publisher, tracking information, distribution restrictions)
• Product tree (the products being addressed)
• Vulnerabilities (each CVE with its status for each product)

CycloneDX VEX

CycloneDX, the SBOM standard from OWASP, also supports VEX as part of its Vulnerability Disclosure Report (VDR) capability. CycloneDX VEX can be embedded directly within an SBOM or published as a standalone document. This tight integration with SBOMs makes it practical for organizations already using CycloneDX.

OpenVEX

OpenVEX emerged as a lightweight, purpose-built format specifically for VEX. Developed by the community around Chainguard and others, OpenVEX provides a minimal schema focused purely on VEX statements without the broader advisory framework of CSAF.

VEX and SBOMs: Better Together

VEX and SBOMs are complementary:

• An SBOM tells you what components are in a product
• A VEX document tells you which known vulnerabilities in those components actually matter

Together, they provide a complete picture: here's what's in this software (SBOM), and here's which known vulnerabilities are relevant (VEX). This combination enables consumers to focus their remediation efforts on vulnerabilities that actually pose a risk.

The workflow looks like this:

1. Producer generates an SBOM for their product
2. A vulnerability scanner identifies known CVEs in the SBOM's components
3. Producer analyzes each vulnerability and creates VEX statements
4. Consumer receives both SBOM and VEX
5. Consumer's vulnerability management system filters alerts based on VEX status
6. Consumer focuses remediation on genuinely affected vulnerabilities

Practical Example

Imagine you ship a container image that includes the OpenSSL 3.0.6 library. CVE-2022-3602 (the Retbleed-era OpenSSL vulnerability discussed earlier) affects OpenSSL 3.0.0-3.0.6.

However, your application only uses OpenSSL for outbound TLS connections to known services. CVE-2022-3602 requires the application to verify a malicious X.509 certificate, which in your architecture only happens when connecting to pre-configured, trusted endpoints. You determine that the vulnerability is not exploitable in your product's deployment context.

You issue a VEX statement:

Product: MyApp v2.1.0
Vulnerability: CVE-2022-3602
Status: Not Affected
Justification: Vulnerable code path not reachable - application only 
validates certificates from pre-configured trusted endpoints

Every consumer of MyApp v2.1.0 now knows they don't need to treat CVE-2022-3602 as urgent for this product. The noise is eliminated, and they can focus on vulnerabilities that are actually exploitable.

Challenges and Limitations

VEX isn't a silver bullet. Several challenges remain:

Producer Effort

Creating VEX documents requires the producer to analyze each vulnerability for each product version. For products with many components and frequent vulnerability disclosures, this is significant ongoing work.

Trust

Consumers must trust the producer's VEX assessments. A "not affected" status from a producer with poor security practices or financial incentive to minimize vulnerabilities may not be reliable. VEX shifts some responsibility for vulnerability analysis from consumer to producer, which requires trust in the producer's competence and honesty.

Timeliness

VEX documents need to be updated as new vulnerabilities are discovered and as analysis is completed. A stale VEX document is worse than no VEX document, because it may give false assurance about newly discovered vulnerabilities.

Tooling Maturity

As of mid-2022, tooling for creating, distributing, and consuming VEX documents was still maturing. Integration with vulnerability management platforms and CI/CD pipelines was in early stages.

Scope Complexity

The "not affected" determination often depends on deployment context. A vulnerability might be exploitable in one deployment configuration but not another. VEX needs to either account for this variability or clearly state the assumptions behind each assessment.

Getting Started with VEX

For software producers looking to adopt VEX:

1. Start with your SBOM. You need to know what's in your software before you can assess which vulnerabilities affect it.
2. Choose a format. If you're already using CycloneDX for SBOMs, CycloneDX VEX is a natural fit. If you need a standalone advisory format, CSAF VEX provides the most complete framework.
3. Prioritize high-impact vulnerabilities. You don't need to issue VEX for every CVE. Start with critical and high severity vulnerabilities that generate the most customer inquiries.
4. Automate where possible. Some VEX determinations can be automated through reachability analysis — static analysis that determines whether vulnerable code paths are actually invoked by your application.
5. Publish and distribute. Make your VEX documents easily discoverable alongside your SBOMs and release artifacts.

How Safeguard.sh Helps

Safeguard.sh integrates VEX into its vulnerability management workflow, allowing both producers and consumers to benefit from exploitability context. For producers, our platform assists in generating VEX statements by analyzing dependency usage and code reachability. For consumers, Safeguard.sh automatically applies VEX data to filter vulnerability alerts, ensuring your security team focuses on the vulnerabilities that actually pose a risk to your specific products. The result: less noise, faster remediation, and more efficient use of limited security resources.