In today’s complex software supply chains, understanding and managing vulnerabilities is a top priority. A Software Bill of Materials (SBOM), like the OWASP® CycloneDX format, provides an “ingredients list” of all components in a software system. However, once you know what’s inside, the next challenge is communicating and acting on vulnerabilities found in those components. This is where two key concepts come in: the Vulnerability Disclosure Report (VDR) and the Vulnerability Exploitability eXchange (VEX). These companion documents add vital context to an SBOM – detailing known vulnerabilities and whether they’re actually exploitable in a given product or environment.
This blog offers an in-depth look at VDR and VEX in the context of the CycloneDX SBOM and OWASP® Dependency-Track. The goal is to provide clarity for both technical teams and decision-makers, showing why adopting VDR and VEX is quickly becoming a security best practice.
Understanding VDR and VEX
Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange (VEX) serve complementary roles in vulnerability management. Both are standardized ways to communicate information on vulnerabilities, but they focus on different aspects:
VDR (Vulnerability Disclosure Report)
A VDR is a structured report of vulnerabilities known to affect a product’s components or services. It provides essential details like which components or versions are affected, the nature of each vulnerability, its severity and often includes remediation or mitigation steps. Essentially, a VDR is like an advisory: it lists all the known vulnerabilities (both in third-party libraries and first-party code) relevant to a particular software system. CycloneDX’s VDR capability allows documenting not only known CVEs inherited from open-source or third-party components, but even newly discovered (previously unknown) vulnerabilities in the product. By including details such as sources of vulnerability information, severity scores and recommended fixes, a VDR paints a comprehensive picture of the product’s vulnerability status at a point in time. This concept aligns with international standards like ISO/IEC 29147:2018 (guidelines for vulnerability disclosure) to ensure all necessary information is communicated. In practice, software vendors might publish a VDR alongside an SBOM to inform users “Here are the vulnerabilities that we know affect the components in this product, and here’s what we’re doing about them.”
VEX (Vulnerability Exploitability eXchange)
Not all listed vulnerabilities pose an actual risk. VEX is a format focused on answering the question: “Is a given vulnerability exploitable in the specific context of this product or deployment?”.
A VEX report provides statements about whether vulnerabilities in components are affected or not affected (or under what conditions they are exploitable) in the product’s context. For example, a library might have a known flaw, but if the product doesn’t use the vulnerable function of that library, the vulnerability might be classified as not exploitable (sometimes called a “vulnerability exclusion”). VEX communicates these nuances. It might say, “Component X has CVE-1234, but our product is not affected by it because the vulnerable code is never invoked.” This clarity helps teams prioritize – fixing the issues that do pose a risk, without getting distracted by ones that don’t.
In essence, VEX acts as a filter on the VDR’s list of vulnerabilities, highlighting which entries are truly dangerous in context and which are benign. CycloneDX treats VEX as a subset of VDR information: it uses much of the same data but adds an “exploitability” status. VEX documents often include an analysis section explaining why a vulnerability is not exploitable or is mitigated in this scenario.
VDR vs. VEX – Roles and Differences
A helpful way to remember the difference is that VDR is about what’s vulnerable, and VEX is about what it means. The VDR lists vulnerabilities affecting components, while VEX indicates whether those vulnerabilities actually affect the product’s security. According to the CycloneDX specification, “VEX is a subset of VDR”. In practice, a VDR might enumerate ten known CVEs in a product’s open-source dependencies, and a corresponding VEX might say that, out of those ten, perhaps two are exploitable and eight are not (due to how the components are used). VDR is broad and disclosure-oriented (useful for transparency and collaboration), whereas VEX is narrow and context-oriented (useful for risk assessment). Both are machine-readable and standardized so they can be automated and integrated into tooling.
Practical Use Cases
Both VDRs and VEX documents have important real-world uses:
- A software vendor issuing a security advisory could provide a VDR to customers with details of all known vulnerabilities in their product’s components (including severity and patches). Alongside it, they might provide a VEX to assure which vulnerabilities do not impact the product’s security (reducing unnecessary alarm). For instance, during the notorious Log4j vulnerability disclosure (Log4Shell), many vendors informed customers via advisories. A VDR would list “Log4j 2.x – CVE-2021-44228 – Remote code execution – patch available”, and the VEX might add “Status: Not exploitable in ProductX because the JNDI lookup class is not used in our configuration”. This combination lets customers know the issue exists but also whether they need to take urgent action or not.
- In a coordinated vulnerability disclosure or bug bounty program, when a researcher reports a new security flaw in a product, the company can publish a VDR (also called a vulnerability advisory) to acknowledge the issue, describe its impact, and announce fixes or mitigations. If the vulnerability doesn’t affect all versions or deployments, a VEX can clarify the conditions. For example, “CVE-2025-1111 – buffer overflow in component Y – affects only configurations with feature Z enabled. If you’re not using feature Z, this issue is not exploitable (per our VEX analysis).”
- Internally, an organization using open source components can generate a VDR for an application to catalog all the CVEs found in its dependencies (using automation). The security team can then augment it with a VEX to mark which findings are true positives versus false positives in their context. This report can then guide developers on which vulnerabilities must be fixed first, and inform management about the application’s risk posture.
Now that we have an understanding of what VDR and VEX are and how they differ, let’s explore why they are beneficial and worth the effort.
Benefits of VEX and VDR
Enhanced Transparency and Trust
VDRs (Vulnerability Disclosure Reports) openly share known issues, building confidence among stakeholders.
VEX (Vulnerability Exploitability eXchange) clarifies which vulnerabilities genuinely impact a product.
Improved Risk Prioritization
Teams can focus resources on vulnerabilities that truly matter.
VEX filters out non-exploitable flaws, reducing “false positives” and unnecessary fixes.
Streamlined Communication
Standardized formats enable automated generation, sharing, and integration with tools.
Stakeholders (developers, security teams, and customers) stay aligned on vulnerability status.
Reduced Operational Overhead
False alarms decrease thanks to exploitability clarity in VEX.
Security teams can handle real threats first, saving time and money.
Regulatory and Compliance Benefits
VDR/VEX align with recommended practices (e.g., NIST, ISO) for vulnerability disclosure.
Proactive compliance and responsible disclosure can enhance reputation and meet evolving regulations.
How to Generate VDR and VEX from Dependency Track
To generate VDR and VEX documents from Dependency-Track, you first ingest a CycloneDX SBOM into the platform (often automated via CI/CD), allowing it to scan for known vulnerabilities. Once identified, you can export a Vulnerability Disclosure Report (VDR) that details eacgenerate VDR and VEX documents from Dependency-Track,h issue, its severity, and recommended remediations. Next, by auditing and classifying the exploitability of those vulnerabilities—often marking them as “affected” or “not affected”—you can produce a VEX document that clarifies which vulnerabilities pose an actual risk, streamlining remediation and communication efforts.
Conclusion
By integrating VDR and VEX into your CycloneDX SBOM practices and utilizing tools like Dependency-Track, your organization can significantly strengthen its software supply chain security. These capabilities, once “nice-to-have,” are quickly becoming essential in the face of sophisticated cyber threats. They empower you to not just react to vulnerabilities, but to stay ahead with a clear, prioritized strategy. Adopting VDR and VEX is a proactive step toward better security, better communication, and better trust in the software you build and use – a win for both engineering teams and the leadership that supports them.