Vulnerability Exploitability eXchange (VEX)

The primary function of VEX is to bridge the gap between a raw vulnerability scan and a real-world risk assessment. Without VEX, a Software Bill of Materials (SBOM) generates a massive list of CVEs, many of which are not exploitable in the specific compiled product.

• Contextual Triage: VEX allows a supplier to assert that a component is present but the vulnerable code is not executed.
• Status Assertions: Suppliers can declare a vulnerability as not_affected, affected, fixed, or under_investigation.
• Operational Efficiency: Security teams stop wasting cycles patching unexploitable vulnerabilities and focus on the critical attack surface.

A valid VEX document must provide a technical justification for why a product is not affected by a specific CVE. This transforms the advisory from an opinion into an auditable engineering statement.

• vulnerable_code_not_present: The vulnerable component is included in the SBOM, but the specific flawed function or class was not compiled or linked into the shipping binary.
• vulnerable_code_not_in_execute_path: The flawed code exists in the binary but is unreachable due to configuration, compiler optimizations, or dead code paths.
• inline_mitigations_exist: The product has existing built-in controls, such as ASLR, stack canaries, or strict SELinux policies, that prevent successful exploitation of the vulnerability.

VEX is not a standalone artifact; it is a companion to the Software Bill of Materials. The SBOM provides the ingredient list, while the VEX provides the allergy and safety warnings for those ingredients.

• Dependency Linking: A VEX document references specific components and their unique identifiers found in the SBOM to establish a precise link between the advisory and the inventory.
• Continuous Monitoring: As new vulnerabilities are discovered, suppliers issue updated VEX documents to amend the exploitability status for existing product versions, enabling continuous authorization to operate (cATO).
• Automated Ingestion: Policy engines can automatically parse VEX data to block deployments if a product has an affected status without a corresponding fixed assertion.

For VEX to work at scale across the software supply chain, it must be machine-readable and standardized. Two primary formats have emerged to solve this interoperability challenge.

• CSAF (Common Security Advisory Framework): An OASIS standard that provides a structured, JSON-based format for security advisories. The VEX profile within CSAF defines specific fields for product trees and vulnerability exploitability status.
• OpenVEX: A minimal, community-driven specification designed specifically for VEX use cases. It prioritizes simplicity and direct integration with SBOM formats like SPDX and CycloneDX.
• Interoperability: Both formats aim to be generated by suppliers and consumed by vulnerability scanners to automatically suppress false positives.

VEX fundamentally shifts the responsibility of vulnerability analysis from the end-user to the software supplier. The supplier possesses the deep architectural knowledge required to determine exploitability.

• Authoritative Source: The software vendor who compiled the binary is the only entity that can definitively state if a vulnerable code path is reachable.
• Liability Shift: By issuing a signed VEX document, the supplier assumes the risk of declaring a vulnerability not_affected, providing a contractual and technical basis for that claim.
• Scalable Security: This model prevents every downstream consumer from having to reverse-engineer a product to determine if a critical CVE applies to them, democratizing supply chain security.

Government cybersecurity mandates are increasingly moving toward requiring SBOM and VEX as baseline requirements for software procurement, particularly in critical infrastructure sectors.

• Executive Order 14028: The US mandate on improving the nation's cybersecurity explicitly calls for artifacts that provide transparency into the software supply chain, with VEX being the logical mechanism for vulnerability transparency.
• CISA Guidance: The Cybersecurity and Infrastructure Security Agency actively promotes VEX as the tool to help organizations prioritize remediation by understanding the exploitability of vulnerabilities in their specific environments.
• EU Cyber Resilience Act: The proposed regulation requires manufacturers to identify and document exploitable vulnerabilities for the lifecycle of the product, a process directly facilitated by continuous VEX updates.