CycloneDX VDR: what a Vulnerability Disclosure Report is and how it differs from VEX

A VDR is built from the same vulnerabilities array every CycloneDX document uses, but populated for disclosure rather than for triage. Per the CycloneDX v1.6 JSON schema, each vulnerability entry can carry id, source, ratings (severity), cwes, description, detail, recommendation, workaround, proofOfConcept, advisories, created, published, updated, rejected, credits and tools — the fields a reader needs to understand a vulnerability, not just act on it. CycloneDX's capability page adds that a VDR also represents "the known completeness of vulnerability intelligence," which maps to the schema's compositions object: its aggregate field takes values such as complete, incomplete, incomplete_third_party_only or unknown, letting a manufacturer state honestly how much of the product's vulnerability surface the report actually covers.

CycloneDX treats VDR and VEX as two separate capabilities built on the same vulnerabilities array, not two versions of the same thing. A VDR discloses everything currently known about vulnerabilities in a product — including ones still in triage — to external parties such as customers, researchers or regulators; that is why CycloneDX also calls it a Vulnerability Advisory Report. A VEX statement instead asserts one specific thing: the exploitability of an already-identified vulnerability in the context of one product, using the analysis.state enum (exploitable, not_affected, in_triage, resolved, and related values) our CycloneDX VEX guide covers in full. A VDR can be published with vulnerabilities that have no analysis object yet, because they have not been triaged; a VEX document is only useful once an underlying vulnerability has already been identified somewhere, frequently in a VDR or an NVD/KEV entry.

A VEX-only document is typically narrow: it populates analysis and affects, often referencing components in a separately published BOM through CycloneDX's bom-link mechanism rather than repeating the full component inventory. A VDR is wider: alongside the vulnerability identifiers it adds description and detail (what the vulnerability is), ratings (severity, usually CVSS), recommendation and workaround (what to do about it now), advisories (links to the vendor's own published advisory), and credits (who found it) — the narrative and provenance fields a reader outside the engineering team needs, which a pure exploitability flag does not carry.

VDR and VEX shipped together in CycloneDX v1.4, released January 2022 — CycloneDX's own history page credits that release as "the first specification to introduce vulnerability sharing and transparency, including Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange (VEX)." CycloneDX has since become an Ecma International standard (CycloneDX v1.6 was ratified as ECMA-424 in June 2024), and the current specification, v1.7 (October 2025), still carries the same vulnerabilities and compositions objects a VDR is built from — the capability has not been dropped or replaced in five subsequent releases.

The capability is schema-native, not a convention layered on top: any CycloneDX-conformant tool that populates the vulnerabilities array with the disclosure-oriented fields above, and sets a compositions.aggregate value, is producing a VDR by CycloneDX's own definition — no separate file format or extension is required. SoftWSP generates a firmware SBOM directly from binary images and can populate the same vulnerabilities array with a VDR's disclosure fields (description, severity, advisories, completeness) alongside the VEX analysis fields for vulnerabilities already triaged, so a device maker can publish one document that both discloses what is known and states what has been assessed. See PSIRT as a service for how that fits into an ongoing disclosure process, and our firmware SBOM guide for how the underlying component inventory is built when no source code is available.

This guide is based on CycloneDX's own VDR and VEX capability pages, its specification history and overview pages, and the published bom-1.6.schema.json vulnerability and compositions definitions in the CycloneDX specification repository, all read directly for this guide. Verify against the current CycloneDX JSON schema at github.com/CycloneDX/specification before relying on a specific field name in tooling you build.