What is a VDR? The vulnerability disclosure report, explained
A VDR (vulnerability disclosure report) lists the known vulnerabilities affecting the components in a product - the result of matching an SBOM against vulnerability data. A VEX then states, per vulnerability, whether the product is actually affected. Together: the SBOM says what is inside, the VDR says what is known to be vulnerable, and the VEX says what actually matters.
A VDR, a vulnerability disclosure report, is a machine-readable record of the known vulnerabilities affecting the components in a product. It is what you get when you take a software bill of materials and match it against vulnerability data: for each component, the CVEs known to affect that version, assembled into one report. Formats such as CycloneDX express VDRs directly, alongside the SBOM they derive from.
Where the VDR sits
Three artifacts describe a product’s component risk, and they answer three distinct questions:
- The SBOM answers what is inside - the component inventory.
- The VDR answers what is known to be vulnerable - the inventory matched against vulnerability data.
- The VEX answers what actually matters - which of those vulnerabilities the product is genuinely affected by, with justifications for the ones it is not.
Read in sequence, they move from a raw list of ingredients to an honest statement of real exposure. The VDR is the middle step: broader than the VEX, because it reports everything matched before exploitability analysis narrows it, and derived entirely from the SBOM, because it is only as complete and accurate as the inventory it started from.
Why the SBOM quality determines the VDR quality
A VDR cannot report a vulnerability in a component the SBOM never listed. So the failure modes of poor SBOMs propagate directly: a shallow inventory that misses transitive dependencies produces a VDR blind to their vulnerabilities, and an inaccurate inventory that lists the wrong versions produces a VDR full of vulnerabilities that do not apply. This is the practical reason the bill-of-materials discipline - generate from real builds, resolve the full graph, declare known-unknowns - is not paperwork: everything downstream, the VDR included, inherits its rigor or its rot.
The pairing with VEX
A VDR alone tends to over-report, because containing a vulnerable component is not the same as being exploitable through it. That gap is what VEX fills: the party who knows - usually the supplier - asserts, per vulnerability, whether the product is affected, with standardized justifications for the not-affected cases. The mature workflow issues both: the VDR for transparency about what was found, and the VEX to tell recipients which findings to act on and which are already assessed as harmless.
In practice
The engines that generate inventories emit VDR and VEX from them as standard outputs rather than as a separate exercise - SecuDep produces the SBOM and the VEX skeletons; the dashboard performs the matching that yields the VDR and tracks the VEX decisions over time; and BOMNexa manages the whole set across releases, so that when a new vulnerability is disclosed, the VDR for an already-shipped build updates without re-scanning it.
Frequently asked questions
What is the difference between a VDR and a VEX?
A VDR reports the vulnerabilities found to affect a product's components - it is the raw matching result. A VEX makes an assertion about exploitability - for each vulnerability, whether the product is actually affected and, if not, why. The VDR is the finding; the VEX is the verdict. You generally issue both: the VDR for transparency, the VEX to cut it down to what is real.
How is a VDR produced?
By matching a component inventory - an SBOM - against vulnerability databases. The quality of the VDR therefore depends entirely on the quality of the SBOM underneath: a shallow inventory produces a VDR that misses vulnerabilities, and an inaccurate one produces a VDR full of noise.
Do I have to share a VDR with customers?
It depends on your obligations and your posture. Some regulated contexts and enterprise contracts expect vulnerability transparency; others prefer a VEX that states affected-status without publishing the full list. Because both are machine-readable and derived from the SBOM, producing them is an emit step rather than a separate project.