VEX -- Vulnerability Exploitability eXchange -- has been the buzzword in vulnerability management circles for three years now. The premise is simple and compelling: instead of treating every CVE that matches a component in your SBOM as an active threat, VEX documents let software suppliers communicate whether a specific vulnerability actually affects their product, and if so, how.
The promise is less noise, faster triage, and more accurate risk assessment. But how is VEX working in practice? We talked to six organizations that have been producing or consuming VEX documents for at least six months. Here is what they have learned.
Quick VEX Primer
A VEX document makes a statement about the relationship between a software product and a vulnerability. There are four possible statuses:
- Not Affected -- the vulnerability exists in a component we use, but our product is not affected (the vulnerable code path is not reachable, we use a hardened configuration, etc.)
- Affected -- our product is affected by this vulnerability
- Fixed -- we have remediated this vulnerability in this version
- Under Investigation -- we are still determining whether our product is affected
VEX documents can be standalone (separate from the SBOM) or embedded within a CycloneDX SBOM. The two main VEX formats are CSAF (Common Security Advisory Framework) and CycloneDX VEX.
Case Study 1: Financial Services Platform
A mid-sized fintech company producing a payments platform began generating VEX documents for their customers in Q1 2025. They process about 200 unique CVEs per month across their product line.
What they did: Integrated VEX generation into their vulnerability triage workflow. When the security team evaluates a CVE, they record their finding as a VEX statement. These statements are bundled into CSAF documents and published alongside each release.
Results: Of the 200 monthly CVEs that match their SBOM components, they mark an average of 142 (71%) as "Not Affected." This means their customers who consume VEX can immediately dismiss 71% of the vulnerability findings that would otherwise require investigation.
Key lesson: "The hardest part is not the tooling -- it is the decision process. You need clear criteria for what constitutes 'not affected' versus 'under investigation.' We spent three months developing decision trees before we published a single VEX document."
Challenge they faced: Their downstream customers had varying levels of VEX consumption capability. Some had tools that could ingest CSAF automatically. Others were manually reading the documents. They ended up producing both machine-readable CSAF and human-readable advisories from the same data.
Case Study 2: Medical Device Manufacturer
A medical device company was among the first in their sector to adopt VEX, driven by FDA premarket cybersecurity guidance that explicitly references SBOM and VEX.
What they did: They produce VEX documents for every software release of their connected medical devices. Given the regulatory context, their VEX documents are exceptionally detailed -- each "Not Affected" statement includes a justification category and supporting evidence.
Results: Reduced the vulnerability findings that hospital IT teams need to investigate by 64%. For a device with 847 components, this means going from ~90 vulnerability alerts per quarter to ~32.
Key lesson: "VEX forced us to actually understand our dependency tree at a level we had not before. The process of determining exploitability for each vulnerability revealed that we had several unnecessary dependencies that we then removed entirely."
Challenge they faced: Producing VEX at the pace that new CVEs are published requires dedicated staffing. They eventually automated initial triage using reachability analysis tools, with human review for edge cases and all "Affected" determinations.
Case Study 3: Enterprise Software Vendor
A large enterprise software company began consuming VEX documents from their own suppliers in mid-2024.
What they did: They updated their vulnerability management platform to ingest VEX documents alongside SBOMs. When a VEX document marks a vulnerability as "Not Affected" for a component they use, their system automatically suppresses the finding (with an audit trail showing the VEX justification).
Results: Alert volume dropped 43% across their monitored portfolio. More importantly, the remaining alerts had a significantly higher true positive rate -- security team productivity improved because they spent less time investigating non-issues.
Key lesson: "Trust is everything. We do not blindly accept VEX from every supplier. We maintain a VEX trust tier system -- Tier 1 suppliers' 'Not Affected' statements are auto-accepted, Tier 2 are accepted with audit flag, and Tier 3 require manual verification. Tier assignment is based on the supplier's track record."
Challenge they faced: Getting suppliers to produce VEX documents in the first place. Only 12 of their 47 critical suppliers provide VEX as of mid-2025. The rest still require manual vulnerability triage.
Common Patterns and Pitfalls
Across all six organizations we spoke with, several themes emerged:
VEX is Not a Silver Bullet for Alert Fatigue
VEX reduces false positives -- vulnerabilities that exist in a component but do not affect the specific product. It does not reduce the volume of genuine vulnerabilities that need remediation. Organizations that expected VEX to eliminate their vulnerability management workload were disappointed. It shifts the workload from consumers to producers, which is more efficient but does not eliminate it.
Quality Varies Wildly
Some VEX documents are meticulously documented with specific justifications for each determination. Others are bulk "Not Affected" statements with no supporting evidence. The industry needs quality standards for VEX, not just format standards.
Automation is Essential for Producers
Manually triaging every CVE against every product version is unsustainable at scale. Organizations that succeeded with VEX production all invested in reachability analysis tooling to automate the initial determination of whether vulnerable code paths are reachable. Human review is reserved for ambiguous cases and for quality assurance sampling.
VEX Distribution is an Unsolved Problem
There is no standard channel for distributing VEX documents. Some suppliers publish them on their website. Some include them in release packages. Some email them to customers. The lack of a standard discovery and distribution mechanism is a significant barrier to adoption.
Versioning Creates Complexity
A VEX statement is valid for a specific version of a specific product. When a new version is released, all "Under Investigation" statements need to be re-evaluated. When a component is updated, "Not Affected" statements may no longer be valid. Managing VEX documents across product version matrices quickly becomes complex.
The Road Ahead
VEX adoption is at the "early majority" stage. The organizations benefiting most from VEX are those that:
- Have clear internal processes for vulnerability triage
- Invest in reachability analysis for automated initial determinations
- Treat VEX as a continuous process, not a one-time artifact
- Build trust frameworks for evaluating VEX from suppliers
- Use tooling that integrates VEX consumption into existing vulnerability management workflows
The standard is mature enough to use. The tooling is catching up. The missing piece is adoption breadth -- we need more suppliers producing VEX documents, and we need better infrastructure for distributing them.
How Safeguard.sh Helps
Safeguard.sh supports both VEX production and consumption. For software producers, our platform generates VEX documents from your vulnerability triage decisions, using reachability analysis to automate initial determinations. For consumers, Safeguard ingests VEX alongside SBOMs, automatically adjusting vulnerability findings based on supplier VEX statements with configurable trust levels. Our policy gates integrate VEX status, so a vulnerability marked "Not Affected" with supporting evidence does not block your deployment, while one marked "Affected" triggers the appropriate remediation workflow.