Vulnerabilities

In VEX and VDR documents, vulnerabilities must be uniquely identified using established naming schemes. This page covers how vulnerabilities are identified and referenced within the SBOM ecosystem.

Vulnerability identifiers

Vulnerability identities in VEX and VDR documents must enable precise correlation with vulnerability databases:

• CVE identifiers — use CVE numbers as the primary identifier when available
• Alternative schemes — for vulnerabilities without CVEs, use established alternatives (e.g., GHSA for GitHub advisories)
• Internal identifiers — for internally discovered vulnerabilities not yet assigned public identifiers, use a consistent internal scheme that prevents collision with other manufacturers

Vulnerability in SBOMs vs. VEX

• SBOMs list components and may reference known vulnerabilities, but do not communicate exploitability.
• VEX communicates whether a specific vulnerability actually affects a product (see VEX / VDR).

Best practice: pair SBOMs with VEX statements rather than embedding vulnerability status directly in the SBOM.

Vulnerability content requirements (VDR)

Each vulnerability record in a VDR must have:

• A list of affected components or products, using identifiers consistent with SBOM entries (purl, CPE, etc.). The affected component can also be included as the Subject of the document.
• A unique identifier and source (e.g., CVE, GHSA, internal ID) to establish an unambiguous identity.
• A title, description, and status (e.g., open, under investigation, resolved, rejected).
• A discovery date, public disclosure date, and optionally a last updated date.
• Severity and scoring information (e.g., CVSS v3.1 or v4.0 vectors).
• One or more references to supporting advisories, patches, commits, or affected versions.
• A justification or resolution statement describing mitigation, patch availability, or reason for rejection.

See the VEX / VDR page for full VEX and VDR requirements and examples.