Vulnerability Exploitability Exchange (VEX)

• VEX is a machine-readable format that augments SBOMs by precisely specifying the exploitability status of vulnerabilities to reduce false alerts.
• It enables vendors to annotate vulnerabilities as affected, not affected, under investigation, or fixed, thereby guiding effective remediation and risk prioritization.
• Empirical evaluations reveal low consensus among VEX tools, highlighting challenges in standardization and the need for improved vulnerability reporting frameworks.

The Vulnerability Exploitability eXchange (VEX) is a machine-readable format designed to augment Software Bills of Materials (SBOMs) by unambiguously specifying the exploitability status of known vulnerabilities present in software components. While SBOMs enumerate all packaged dependencies, VEX enables vendors to communicate whether listed vulnerabilities are exploitable, mitigated, or irrelevant in the product’s context. This distinction is crucial for reducing false positives, prioritizing remediation, and improving software supply-chain transparency (Ekstedt, 18 Mar 2025).

1. Motivation and Purpose

Traditional SBOMs systematically catalog the components within software artifacts, but they lack actionable risk assessment with respect to known vulnerabilities. Not all vulnerabilities nominally present in included libraries or binaries are reachable, exploitable, or relevant for the final deployed product—a challenge commonly leading to a high volume of spurious vulnerability alerts (false positives). VEX addresses this gap by allowing vendors to annotate the SBOM's inventory with structured statements regarding each vulnerability, denoting whether it is "affected," "not affected," "under investigation," or "fixed," and supplying requisite justifications for non-exploitable cases. This enables more precise triage, resource allocation for patching efforts, and strengthens consumer trust in vendor-supplied assurance artifacts (Ekstedt, 18 Mar 2025).

2. VEX Schema and Serialization

VEX documents are serialized using two primary, functionally equivalent representations: CSAF-based and CycloneDX-based schemas. Both approaches encapsulate the essential fields necessary to communicate exploitability status at both the component and vulnerability level.

Field	Purpose	Typical Values / Notes
Product Identifier	Designates the assessed product/version or product family	String, version or range
Component Identifier	Identifies the specific sub-component/library/vulnerable entity	Name (often package), version, packaging conventions
Vulnerability ID	Enumerates the flaw under assessment	CVE, GHSA, DSA, NPM advisory, or textual description
Status	Declares exploitability assessment	"affected", "not affected", "under investigation", "fixed"
Status Justification	Mandatory when "not affected"; codified rationale	Examples: "code not present", "unreachable code path"
Mitigation	Remediation advice for "affected" vulnerabilities	Upgrade, patch, "will not fix" statement
Timestamp	Report generation datetime	ISO 8601 or similar format
Document Version	Versioning for VEX schema evolution	Integer, semver, etc.
Metadata	Auxiliary info: severity, URLs, advisory refs	CVSS score, data source (NVD, GitHub, Snyk), etc.

The controlled vocabulary for justifications varies: CSAF defines five canonical options; CycloneDX extends this set to nine. This uniformity underpins both human and automated processing of VEX entries (Ekstedt, 18 Mar 2025).

3. VEX Workflow: Generation and Consumption

In operational settings, the VEX process unfolds as follows: a vendor constructs an SBOM (listing all incorporated components), then issues a corresponding VEX artifact. For each vulnerability potentially relating to a component (e.g., as identified by CVE, GHSA, DSA), a status is declared and—when inapplicable—justified. Consumers then cross-reference their SBOMs and VEX advisories, enabling actionable assessment of risk exposure in downstream products. The capacity to quickly distinguish “not affected” from “affected” vulnerabilities confers significant efficiency in triage and patch management (Ekstedt, 18 Mar 2025).

4. Empirical Evaluation: Consistency of VEX Toolchains

A systematic study by Churakova and Ekstedt evaluated the consistency of seven state-of-the-art, open-source “VEX-producing” vulnerability scanners: Grype, Trivy, DepScan, OSV-scanner, Docker Scout, Vexy, and the Snyk CLI. Each tool can output findings in CycloneDX or SPDX VEX formats. The analysis was performed over 48 container images sourced from Docker Hub, grouped as follows:

• “Non-Vulnerable”: 8 images claimed by the registry to be free of vulnerabilities.
• “Vulnerable”: 8 images with highest reported counts.
• “Random”: 32 randomly selected images.

The study employed both image-based and SBOM-based scanning modes, with a total of 25 tool configuration variants. To compare outputs, each tool’s VEX findings were reduced to triplets (image name, component identifier, vulnerability identifier), and similarities were assessed using the Jaccard Index and Tversky Index:

$J(A,B) = \frac{|A \cap B|}{|A \cup B|}$

$$T_{\alpha,\beta}(A,B) = \frac{|A \cap B|}{|A \cap B| + \alpha |A\setminus B| + \beta |B\setminus A|}$$

These metrics quantify both pairwise overlap and multi-tool consensus in reported vulnerabilities (Ekstedt, 18 Mar 2025).

5. Key Findings on Tool Consistency and Maturity

Analysis revealed strikingly low consistency among tools purporting to implement the VEX specification:

• Highest pairwise Jaccard (Trivy vs Grype): ~0.69; other pairs typically <0.4 and some near zero.
• Restricting to CVE-only results raises Trivy/Grype overlap to ~0.76, but systematic improvement is not observed for other pairs.
• Consensus across groups of five or six tools (via Tversky Index) falls below 4%—in several instances, no common vulnerabilities are reported.
• Use of a single SBOM across tools does not notably improve alignment (<0.3 Jaccard).
• Attempts to normalize by vulnerability namespace or strip temporary IDs only marginally affect results.
• A strong correlation (Pearson r = 0.88) exists between overlapping vulnerability database sources queried and tool similarity.

The empirical evidence thus indicates that, despite the normalization promise of VEX, real-world scanners generate divergent exploitability assertions. This reflects an immature ecosystem where lack of standardization and disparate data sources undermine consumer confidence and the reliability of VEX-based processes (Ekstedt, 18 Mar 2025).

6. Sources of Inconsistency and Research Directions

Three primary drivers are hypothesized for the observed inconsistency:

1. Inconsistencies in SBOM generation and component naming/identification.
2. The “naming problem” in vulnerability reporting, including incomplete aliasing and mapping across CVE, GHSA, DSA, SNYK, and other namespaces.
3. Variations in vulnerability database coverage, including tools omitting required VEX fields (especially OSV-scanner and Vexy).

To address these challenges, the following research and development priorities are recommended:

• Create authoritative ground-truth datasets for narrowly defined domains to permit rigorous false positive/negative measurement.
• Standardize component naming and implement cross-database identifier resolution (e.g., via a universal alias registry or OSV-style aggregator).
• Extend VEX to reference actual exploitability evidence—such as proof-of-concept links or exploit maturity descriptors—thereby increasing objectivity of “not affected” justifications.
• Benchmark SBOM generation tools and scanner/database mapping independently to isolate error sources.
• Advocate for tool vendors to use a common minimum vulnerability feed baseline and to uniformly populate VEX-required fields (notably status justification and mitigation details) (Ekstedt, 18 Mar 2025).

7. Significance, Limitations, and Outlook

VEX stands as an essential complement to SBOMs, offering the potential for automated, actionable vulnerability triage in software supply chains. However, in current practice, the ecosystem of VEX-producing tools is hampered by inconsistent output, attributable to the interplay of incomplete standardization, heterogeneous database coverage, and unresolved namespace mapping. The lack of a shared “ground truth” for container images further complicates assessment of scanner accuracy and precision, motivating the need for designated benchmark datasets and neutral evaluation frameworks.

While VEX promises to supplant unfiltered vulnerability enumeration with context-specific exploitability judgments, the tooling and associated standards require substantial refinement, community coordination, and research effort to realize this objective (Ekstedt, 18 Mar 2025).