VEX / VDR

Vulnerability Exploitability eXchange and Vulnerability Disclosure Report requirements

Relationship between SBOM, VEX, and VDR

SBOM (Software Bill of Materials) is a structured inventory that lists the components, dependencies, and versions included in a software product at a specific point in time.
VEX (Vulnerability Exploitability eXchange) provides details about whether known vulnerabilities for any of the components listed in the SBOM impact a specific software assembly.
VDR (Vulnerability Disclosure Report) provides information about privately or publicly disclosed vulnerabilities affecting components or services in the delivered software. This may include information not yet published in public vulnerability databases.

VEX Requirements

VEX documents provide an assessment of the impact and exploitability of specific vulnerabilities in a specific application or system. They complement SBOMs and advisories by clarifying exploitability in the intended environment and enabling more accurate risk assessments.

VEX documents are key enablers for prioritisation and automation of vulnerability management workflows. Typically multiple VEX documents are delivered to reflect the progress of the analysis and mitigation of a vulnerability.

High-level VEX requirements

#	Description	Reference
1	The subject (affected component) of a VEX document must be documented in an SBOM	SBOM Requirements
2	The subject of a VEX document must contain the same identifiers (name, versions, purl etc) as used in SBOMs	Components
3	VEX should be delivered as document separate from SBOM
4	VEX must be in one of the standardized formats CycloneDX, SPDX or CSAF with JSON encoding	Formats
5	VEX document must have a unique identifier	SBOM Metadata
6	VEX must be timestamped	SBOM Metadata
7	The manufacturer or author that created the VEX should be documented	Suppliers
8	Tools used to create the VEX should be documented	SBOM Tools
9	Each analysis in the VEX must have information about state, justification and response
10	Each analysis in the VEX must be timestamped
11	Each analysis in the VEX should have a detailed description of the impact and methods used during assessment
13	Vulnerabilities referenced in the VEX must have a unique identifier and source to establish an unambiguous identity	Vulnerabilities
14	Vulnerabilities referenced in the VEX that are not published publicly must include a full VDR	VDR Requirements
15	VEX should be signed by publisher, supplier, or certifying authority	Suppliers

In addition to the required VEX information, a VEX document can contain any and all of the VDR information if it enables consumers to better understand the context, impact, and remediation of reported vulnerabilities.

VEX example — CycloneDX 1.6

Single Product, Single Version, Single Vulnerability, Single Status:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:6a912f42-1f4b-46bb-8f08-6b7bb68a5d3c",
  "version": 1,
  "metadata": {
    "timestamp": "2025-03-25T10:45:00Z",
    "supplier": {
      "name": "Example Inc",
      "url": [
        "https://example.com"
      ],
      "contact": [
        {
          "name": "John Doe",
          "email": "john@example.com"
        }
      ]
    },
    "component": {
      "bom-ref": "a05bbca7-f783-44cd-aafb-f5284f81473f",
      "type": "application",
      "name": "example-application",
      "version": "1.0.0",
      "purl": "pkg:swid/Example%20Inc/example.com/example-application@1.0.0?tag_id=a05bbca7-f783-44cd-aafb-f5284f81473f"
    }
  },
  "vulnerabilities": [
    {
      "bom-ref": "vuln-CVE-2025-4575",
      "id": "CVE-2025-4575",
      "source": {
        "name": "openssl-library.org",
        "url": "https://openssl-library.org/news/vulnerabilities/#CVE-2025-4575"
      },
      "ratings": [
        {
          "score": 7.5,
          "severity": "high",
          "method": "CVSSv3"
        }
      ],
      "affects": [
        {
          "ref": "pkg:generic/openssl@3.0.15"
        }
      ],
      "analysis": {
        "state": "not_affected",
        "justification": "requires_dependency",
        "response": [
          "will_not_fix"
        ],
        "detail": "This application includes a patched version of OpenSSL (3.0.15+patched) which resolves CVE-2025-4575.",
        "lastUpdated": "2025-03-25T10:13:00Z"
      }
    }
  ]
}

References

Reference	Notes
CycloneDX VEX	CycloneDX introduction to VEX
CycloneDX CISA Use-cases	Examples mapping to CISA VEX use cases

VDR Requirements

VDR (Vulnerability Disclosure Report) documents provide structured information on vulnerabilities, privately or publicly disclosed, discovered and addressed during development or maintenance. They capture how issues were identified, resolved, and communicated, supporting transparency across the software lifecycle.

VDR is the primary information source for privately disclosed vulnerabilities and advisories. VDR can also be used to provide additional or curated information for publicly disclosed vulnerabilities.

High-level VDR requirements

#	Description	Reference
1	The subject (affected component) of a VDR document must be documented in an SBOM	SBOM Requirements
2	The subject of a VDR document must contain the same identifiers as used in SBOMs	Components
3	VDR should be delivered as document separate from SBOM
4	VDR must be in one of the standardized formats CycloneDX, SPDX or CSAF with JSON encoding	Formats
5	VDR document must have a unique identifier	SBOM Metadata
6	VDR must be timestamped	SBOM Metadata
7	The manufacturer or author that created the VDR should be documented	Suppliers
8	Tools used to create the VDR should be documented	SBOM Tools
9	Each vulnerability record must be compliant with the vulnerability content requirements	Vulnerabilities
10	When a vulnerability is not publicly disclosed, the VDR must include all relevant details necessary for consumers to perform internal risk assessment	Vulnerabilities
11	VDR should be signed by publisher, supplier, or certifying authority	Suppliers

VDR example — CycloneDX 1.6

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:9c3e4f2a-8b7d-4c1e-9f3a-2d5e6b8a9c1f",
  "version": 1,
  "metadata": {
    "timestamp": "2025-10-15T10:00:00Z",
    "component": {
      "bom-ref": "a05bbca7-f783-44cd-aafb-f5284f81473f",
      "type": "application",
      "name": "example-application",
      "version": "1.0.0"
    },
    "supplier": {
      "name": "Example Inc",
      "url": [
        "https://example.com"
      ]
    },
    "lifecycles": [
      {
        "phase": "operations"
      }
    ],
    "tools": {
      "components": [
        {
          "type": "application",
          "name": "security-scanner",
          "version": "2.5.0"
        }
      ]
    }
  },
  "vulnerabilities": [
    {
      "id": "INTERNAL-2025-001",
      "source": {
        "name": "Example Inc Security Team",
        "url": "https://security.example.com"
      },
      "description": "Authentication bypass vulnerability in the example-application allows an unauthenticated attacker to gain administrative access by manipulating session tokens.",
      "recommendation": "Upgrade to version 1.0.1 or later.",
      "published": "2025-10-15T10:00:00Z",
      "created": "2025-10-10T14:30:00Z",
      "ratings": [
        {
          "score": 9.1,
          "severity": "critical",
          "method": "CVSSv31",
          "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
        }
      ],
      "cwes": [
        287,
        330
      ],
      "affects": [
        {
          "ref": "a05bbca7-f783-44cd-aafb-f5284f81473f",
          "versions": [
            {
              "version": "1.0.0",
              "status": "affected"
            },
            {
              "version": "1.0.1",
              "status": "unaffected"
            }
          ]
        }
      ],
      "analysis": {
        "state": "in_triage",
        "detail": "Vulnerability confirmed. Patch under development.",
        "firstIssued": "2025-10-10T14:30:00Z",
        "lastUpdated": "2025-10-15T10:00:00Z"
      }
    }
  ]
}

VEX / VDR

On this page