# Vulnerabilities (/docs/content-requirements/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-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 [#vulnerability-in-sboms-vs-vex]

* **SBOMs** list components and may reference known vulnerabilities, but do not communicate exploitability.
* **VEX** communicates whether a specific vulnerability affects a product (see [VEX / VDR](/docs/content-requirements/vex-vdr)).

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

## Vulnerability content requirements (VDR) [#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](/docs/content-requirements/vex-vdr) page for full VEX and VDR requirements and examples.