Signal in the Noise: An Industry-Wide Perspective on the State of VEX

Abstract: Software security has always been a race between complexity and clarity. The Vulnerability Exploitability eXchange (VEX) aims to bring clarity to that race. It’s a structured, machine-readable way for software producers to tell the world whether a vulnerability truly affects their products. That clarity has the potential to cut through noise, eliminate false positives, and reduce the human toil involved in vulnerability management. But for now, adoption remains inconsistent and uncertain. This report collects the stories and insights of leading players in the software industry—Amazon, Aquasec, Chainguard, Cisco, Debian, Ericsson, Freexian, Google, Microsoft, Red Hat, and OpenSUSE. Together, they form a mosaic of progress, frustration, and hope. What follows is not a technical manual. It’s an honest account of how VEX is evolving, what’s holding it back, and how we can build a future where vulnerability data empowers security teams instead of overwhelming them. 

Introduction 

Every day, a security team receives a list of vulnerabilities that looks terrifying. Most of those entries will turn out to be harmless. The challenge is that no one knows which ones matter without a lot of digging. VEX was created to make that process faster and smarter. The Vulnerability Exploitability eXchange is a framework for software producers to publish clear, structured statements about which vulnerabilities do and do not apply to their products. It’s a way to replace endless guesswork with precise, verifiable data. 

And yet, the reality today is that VEX feels more like a promise than a practice. Across the industry, there’s agreement on what VEX could be, but less on how to get there. Formats like CSAF, OpenVEX and CycloneDX offer different visions for VEX documents. SPDX, specifically the upcoming 3.0 specification, takes a relationship-based approach. While it can function as a standalone document, its architecture is designed to encode vulnerability relationships directly into the broader software supply chain graph, capable of ingesting and mapping information from other formats like CSAF or OpenVEX. While organizations wrestle with tooling, policy, and regulation, the VEX Industry Collaboration Working Group brought together experts from across the ecosystem to compare notes and chart a shared path forward. 

Methodology 

This paper draws from months of structured interviews and discussions with major software producers, open source maintainers, and vulnerability management vendors. We listened, compared, and synthesized their experiences into a unified view of VEX adoption. We focused on five big questions: 

• What motivates companies to adopt VEX? 
• Which formats are being used, and why? 
• How are VEX documents distributed and trusted? 
• What tools exist—and what’s missing?
• How are regulations shaping these decisions? 

These conversations were complemented by a comparison of popular existing standards (such as CSAF, OpenVEX, and CycloneDX), as well as regulatory frameworks like the EU Cyber Resilience Act and the U.S. Executive Order on Software Supply Chain Security. 

Note: The insights in this paper largely reflect the perspectives of the enterprise and vendor interviewees listed in the acknowledgments. While valuable, this does not represent an exhaustive audit of all VEX implementations or the wider open source ecosystem. 

Current State of VEX 

Why Companies Care 

VEX adoption is slowly gathering momentum, pulled forward by regulation, customer expectations, and a simple desire to reduce noise. 

• Reducing False Positives: Microsoft reports that common vulnerabilities in libraries like curl generate hundreds of unnecessary support tickets. VEX could stop those calls before they happen.
• Enabling Automation at Scale: With nearly 40,000 new CVEs published annually, communication about vulnerabilities along complex software supply chains can only be handled through automation. Machine-readable VEX is essential for this. 
• Meeting Compliance Requirements: The EU’s Cyber Resilience Act makes effective vulnerability handling a legal requirement for anyone doing business in Europe, and CSAF-based VEX will be a key enabler for efficient compliance. 
• Customer Pressure: Enterprises are asking for VEX data. Cisco now requires it from suppliers through its contractual terms. 

Who’s Doing What 

• Established Implementers: Red Hat, OpenSUSE, and Microsoft are ahead, publishing CSAF VEX documents and building infrastructure to manage them. 
• Emerging Players: Cisco exposes VEX through APIs and is transitioning to CSAF exports. 
• OpenVEX Ecosystem: Chainguard maintains an OpenVEX feed for its secured libraries. The Go toolchain, Kubescape, and Edgebit have integrated OpenVEX for native data generation and reachability analysis. 
• Investigating Participants: Amazon and Debian are experimenting, learning, and planning for broader adoption. 
• Standardization Drivers: Companies like Microsoft, Cisco, and Ericsson are actively evolving the CSAF VEX standard within OASIS to address current and future use cases. 

The Four Flavors of VEX 

Currently, four primary formats exist for implementing VEX, each with distinct characteristics:

• CSAF (Common Security Advisory Framework): A comprehensive standard used heavily by major vendors and aligned with regulatory requirements (like the EU CRA). It is powerful and expressive but can be complex to generate and validate without specialized tooling. 
• OpenVEX: Designed for simplicity, interoperability, and integration into open source workflows. It supports cryptographic attestation (via in-toto) and is supported by tools like the Go toolchain and Docker. It prioritizes “boring” reliability and ease of use over complex advisory features. 
• CycloneDX: A bill-of-materials (SBOM) standard that includes VEX capabilities. While it allows for standalone vulnerability reports, its unique value proposition is embedding vulnerability status directly within the SBOM. However, this can create challenges when SBOM generation lifecycles (build-time artifacts) differ from VEX lifecycles (continuous security updates). 
• SPDX (Software Package Data Exchange): The forthcoming SPDX 3.0 specification includes a full VEX implementation. It is designed to be fully compatible with the CISA VEX “spec of specs,” capable of round-tripping data to and from other formats. 

Challenges and Gaps 

The following challenges reflect the specific pain points identified by our interviewees, particularly those focused on enterprise CSAF implementations. 

Discovery and Distribution 

Finding the right VEX document is harder than it should be. There’s no common lookup system, and trust is uneven. Today, every organization distributes VEX differently: some through APIs, others through static repositories or experimental hubs. Functionally, VEX sits between SBOMs (or attestations) and vulnerability database information. While VEX and SBOMs share the same method of referencing software components, the shape of their distribution problems is not the same. Unlike static build artifacts, VEX documents require frequent and dynamic updates, creating a unique hurdle for automation. 

Verification and Trust 

Verifying the source of a VEX document remains a complex problem for many implementers. While standards like OpenVEX were designed with attestation in mind (e.g., in-toto predicates), widespread industry consensus on a shared standard for signing and verifying all VEX formats is still evolving. Beyond the mechanics of verification, there is the added difficulty of defining the policy itself—determining whose VEX statement to trust (e.g., the software vendor, a distro maintainer, or a third-party scanner). For many enterprise consumers, trust is currently based on where the file is hosted rather than cryptographic proof, which limits the utility of aggregated hubs. 

Tooling Maturity 

The maturity of tooling remains a significant variable in the ecosystem. Our research specifically highlighted challenges regarding CSAF: while the format is powerful, its tooling can be complex for many users. Some official checkers were reported to miss logical errors, and smaller companies often struggle with the custom development required to manage the documents effectively. This gap has forced adopters like OpenSUSE and Debian to build their own internal tools rather than relying on standard implementations. Conversely, OpenVEX has prioritized a “tooling-first” approach, resulting in stable generation and validation libraries in major ecosystems like Go, which lowers the barrier to entry for smaller teams, even if it lacks the full expressive powers of CSAF. 

Mismatched Lifecycles 

A VEX document changes whenever new vulnerability status information appears. An SBOM, typically, is a snapshot of build artifacts. While VEX best practices suggest keeping these lifecycles distinct to avoid confusion, theory and practice often diverge. Formats like CycloneDX allow for embedding VEX information directly within an SBOM (e.g., via VDR or BOV profiles). This approach has valid use cases—such as providing a summary of known vulnerability status at the exact moment of a software release—but our research suggests adoption is limited. Documentation for these specific CycloneDX use cases is often scarce, and the data model for handling complex vulnerability status statements within the SBOM is perceived by some as less mature than standalone VEX implementations. 

Software Identifier Confusion 

Every ecosystem has its own way of naming things (PURLs, CPEs, hashes). Without shared conventions and trusted authorities to map these identifiers, automation breaks down. This is a fundamental metadata problem that affects VEX but is not inherent to the VEX format itself. 

Education and Incentives 

Most open source maintainers don’t see a reason to publish VEX statements. Some vendors treat VEX as a premium feature, not a baseline responsibility. Adoption isn’t just a technical challenge; it’s cultural. 

Role Clarity 

VEX should describe exploitability, not serve as a policy tool for ignoring issues. Blurring those lines makes it harder to trust the data. 

Recommendations 

Build a Common Distribution System 

The community should fund and design a VEX Discovery and Distribution Protocol. This could be hosted under OpenSSF, enabling anyone to discover, verify (via digital signatures or OCI-based attestation), and use trusted VEX data in a consistent way. This effort should leverage existing contributions, such as the potential donation of the Aqua VEX Hub or existing OpenVEX archives, to accelerate the creation of a neutral, federated index. 

Invest in Better Tools

Product teams have made it clear: they cannot adopt these standards without friction-free integration. Regardless of the specific format, the ecosystem urgently needs robust, maintained libraries to generate VEX documents. Bridging the gap between policy requirements and engineering reality requires meeting developers where they are, with reliable tooling in languages like Go, Python and Java. 

Align on Standards Without Excluding Others 

Enterprises should consider CSAF as the target standard for high-fidelity production due to its expressiveness and regulatory alignment. However, the industry must acknowledge the implementation friction reported by product teams. We should support CSAF adoption where necessary without invalidating the use of lighter-weight formats that effectively serve engineering needs. 

Clarify VEX’s Purpose 

The industry should agree on what VEX is—and what it isn’t. That means clear definitions of exploitability reporting, fix availability, lifecycle status (EOL), and legal considerations. A shared guide or reference paper could help bring this clarity. 

Fix the Identifier Problem 

Projects like OpenSSF GUAC can lead the way by defining shared identifier-matching libraries that unify PURLs, CPEs, and hashes. Reliable identifiers are the foundation of reliable automation. 

Strengthen Cross-Industry Collaboration 

The OpenVEX SIG under OpenSSF currently serves as a home for this collaboration. However, driving generic VEX improvements across the ecosystem may require a shift in structure or branding. To effectively signal a format-neutral mission, the industry needs a forum explicitly dedicated to the broader VEX interoperability–focusing on transport and discovery protocols–rather than operating under a specific specification’s banner. 

Lead by Doing 

The fastest way to make VEX real is to use it. 

• Large vendors should start publishing VEX for their own products. 
• Consumers should ask vendors for VEX data. 
• Open source maintainers should engage with the community to find the tools and support you need. 

Future Directions 

The next chapter of VEX will be written not in standards bodies but in the build systems, scanners, and repositories that people use every day.

• CSAF 2.1 Adoption: In the coming year, we should focus on implementing the CSAF 2.1 specification to leverage its flexible identifiers and integration with modern scoring systems like Exploit Prediction Scoring System (EPSS), ensuring these features translate into actual risk reduction. 
• Federated Discovery: OCI registries and projects like Aquasec’s VEX Hub point toward a future of distributed but trusted VEX sharing. 
• Integration with CI/CD: The industry objective should be to normalize VEX generation within standard release pipelines. We should move beyond isolated success stories to a state where automated VEX production is a default capability in major build systems, independent of the specific format used. 
• Regulatory Momentum: The Cyber Resilience Act and similar efforts will turn VEX from a “nice to have” into a key enabler for compliance. 

Acknowledgements 

This work is the result of many conversations, generous expertise, and the steady patience of people who care deeply about making software safer for everyone. The authors extend our sincere thanks to the individuals who contributed their time, insight, critiques, and lived experience. Their perspectives shaped this paper in ways both visible and quiet. 

Authors (listed alphabetically): Aubrey Olandt (Red Hat), Brandon Lum (Google), Charl de Nysschen (Google), Christoph Plutte (Ericsson), Georg Kunz (Ericsson), Jonathan Douglas (Microsoft), Jautau “Jay” White (Microsoft), Martin Prpič (Red Hat), Rao Lakkakula (Microsoft) 

Contributors (listed alphabetically): Adolfo Garcia Veytia (Carabiner Systems), Alex Goodman (Anchore), Brad Bock (Chainguard), Dario Ciccarone (Cisco), Itay Shakury (Aquasec), James Fuller (Red Hat), Jens Reimann (Red Hat), Johannes Segitz (OpenSUSE), Lisa Olson (Microsoft), Lucas Kanashiro (Freexian), Marcus Meissner (OpenSUSE), Omar Santos (Cisco), Philippe Deslauriers (Chainguard), Rex Pan (Google), Samuel Henrique (Debian), Santiago Ruano Rincón (Freexian), Suresh Goacher (Amazon), Teppei Fukuda (Aquasec), Thomas Schmidt (German BSI), Yousef Alowayed (Google).