SBOM Extensions and Related Artifacts

SBOMs describe what a software product contains, but they do not answer every operational question on their own. Related artifacts such as VEX, VDR, attestation, provenance, and PURL add the extra context needed to assess exploitability, verify trust, and identify packages precisely.

VEX — Vulnerability Exploitability eXchange

VEX is the most operationally important companion artifact. It addresses the core problem that a component appearing in an SBOM may carry hundreds of CVEs without any of them being actually exploitable in the product that ships the component. A raw SBOM-plus-CVE-feed correlation produces enormous noise. VEX exists to cut through it.

A VEX statement is a machine-readable assertion that answers the question: for this specific product version, does this specific CVE represent a real risk? The four canonical statuses, established in CISA’s VEX guidance and carried through all three major implementations, are:

not_affected — the product contains the component, but the vulnerability cannot be triggered in the way the product uses it. The producer should provide a justification (e.g., component_not_present, vulnerable_code_not_in_execute_path, inline_mitigations_already_exist).
affected — the vulnerability is present and exploitable. The statement should include remediation guidance.
fixed — the vulnerability existed in a prior version and has been resolved in this one.
under_investigation — the producer is actively assessing the vulnerability’s applicability and will update the statement.

Three implementations, one concept

VEX exists in three interoperable but syntactically distinct implementations today.

CSAF VEX is a profile of the OASIS Common Security Advisory Framework. CSAF is a mature, widely adopted standard for security advisories, and CSAF VEX inherits its distribution and signing infrastructure. It is the preferred format for large enterprise software producers and for organizations already using CSAF for advisory management. The German Federal Office for Information Security (BSI) and CISA have both invested heavily in CSAF tooling and distribution.

CycloneDX VEX can be embedded directly in a CycloneDX BOM or delivered as a standalone BOM document with the vulnerabilities component populated. It is the natural choice for producers already generating CycloneDX SBOMs and for tooling ecosystems built around the CycloneDX standard. CycloneDX 1.5 and later support the full VEX status vocabulary and allow VEX and SBOM to be versioned together.

OpenVEX is a lightweight, format-agnostic specification using JSON-LD, maintained by the OpenVEX project under the OpenSSF umbrella. It is designed to be embedded in other documents, generated by automated tools, and consumed with minimal tooling overhead. OpenVEX is particularly well suited for open source projects and for CI/CD-native VEX generation.

All three carry the same conceptual payload. They differ in syntax, how tightly they bind to an SBOM document, and what distribution infrastructure surrounds them. Tools should aim to consume all three; producers should issue VEX in the format most natural to their SBOM workflow.

VEX across roles

Producers should generate VEX statements for high-profile CVEs affecting components in their shipped software, particularly when the not_affected justification is non-obvious. A VEX statement that correctly marks a component as not_affected with a clear justification saves support hours and builds customer trust. Automating VEX generation from the build pipeline — triggered by new CVE disclosures against known components — is the direction the industry is moving.

Consumers should integrate VEX intake into vulnerability management workflows. The practical effect of a mature VEX flow is triage suppression: instead of evaluating every CVE that touches every component in the inventory, the team focuses on those the producer has not marked not_affected. Where producers do not issue VEX, consumers can generate their own — marking components as not_affected based on internal analysis — to suppress noise in downstream tooling.

Tooling and platform teams need to handle all three VEX formats, correlate VEX statements to the correct SBOM and product version, track VEX statement expiry or supersession, and surface changes in status (e.g., a component moving from under_investigation to affected) as actionable alerts.

Policy and compliance teams should be aware that several regulatory frameworks, including the EU CRA and the FDA’s medical device cybersecurity guidance, either explicitly reference VEX or describe post-market vulnerability monitoring obligations that VEX satisfies operationally.

VDR — Vulnerability Disclosure Report

A VDR is a producer-issued document listing the known vulnerabilities affecting a product, with their status and recommended remediation or mitigation actions. It overlaps conceptually with VEX but is broader, less formally structured, and predates the VEX standardization effort.

CycloneDX defines VDR as a first-class artifact type. NIST SP 800-161r1 (Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations) references VDRs as a component of supplier transparency. In practice, a VDR tends to serve as the human-readable narrative companion to the machine-readable SBOM and VEX — it explains the broader vulnerability posture of a product in a way that security and compliance reviewers can read directly without tooling.

VDR across roles

Producers maintain VDRs as part of ongoing product security documentation. They are particularly valuable for products with long support lifetimes — medical devices, industrial control systems, embedded firmware — where accumulated vulnerability history needs to be accessible across multiple years. A VDR updated at each release and kept alongside the SBOM in a distribution channel is a meaningful disclosure artifact.

Consumers should treat VDRs as a producer’s narrative companion to the SBOM and VEX, not as a replacement for either. A VDR without a corresponding machine-readable SBOM is useful context; it is not an operational artifact. When a vendor provides only a VDR, ask for the SBOM and machine-readable VEX.

Regulated organizations in sectors where post-market surveillance is mandated — FDA-regulated device manufacturers, critical infrastructure operators — should understand that VDRs may be requested by auditors or regulators as evidence of ongoing vulnerability monitoring.

Attestations and provenance

An SBOM becomes significantly more credible when it can be cryptographically tied to a specific build, signed by the producer, and independently verified. Three complementary frameworks provide this infrastructure.

Sigstore and cosign

Sigstore is an open source project providing keyless code signing and transparency log infrastructure, maintained under the OpenSSF. ^[9] cosign, its primary tool, can sign container images, artifacts, and SBOM documents and record the signatures in the Rekor transparency log. The signature proves that a specific SBOM file was produced by a specific identity at a specific time and has not been modified since.

Sigstore is now deeply integrated into the container ecosystem. Most major container registries support cosign signatures, and GitHub Actions workflows can sign artifacts with OIDC-based identities without managing private keys.

in-toto

in-toto is a framework for end-to-end software supply chain integrity. ^[10] Rather than signing only the final artifact, in-toto signs each step in the build pipeline — source checkout, compilation, test execution, packaging — and produces a link metadata file for each. A verifier can replay the entire build process and confirm that each step was performed by the expected actor, with the expected inputs and outputs. in-toto links can accompany an SBOM to prove not just that the artifact exists but that it was built by the described process.

SLSA — Supply-chain Levels for Software Artifacts

SLSA (pronounced “salsa”) is a framework of incrementally achievable supply chain security levels, maintained by the OpenSSF. ^[11] SLSA levels define how much confidence can be placed in the provenance of a software artifact:

SLSA 1 — provenance exists and is generated by the build process.
SLSA 2 — provenance is signed; the build uses a hosted build service.
SLSA 3 — the build service is hardened; provenance is generated by the service itself, not the build script.

SLSA provenance can accompany an SBOM as evidence of how the SBOM was generated. A producer claiming a build SBOM at SLSA 2 or 3 is making a verifiable claim about build integrity; a producer claiming a build SBOM with no provenance is providing a self-asserted document.

CycloneDX Attestations (CDXA)

CycloneDX Attestations (CDXA), introduced in CycloneDX 1.5, provide a structured way to capture compliance claims, evidence references, and conformance assessments alongside an SBOM. ^[12] A CDXA document can assert conformance to a standard (e.g., “this product was built in accordance with NIST SSDF PW.4”), reference the evidence supporting that assertion, and bind the entire package to the SBOM it accompanies.

Attestations across roles

Producers should integrate Sigstore signing into their CI/CD pipeline as a baseline practice. Generating SLSA provenance is increasingly expected for open source projects and is becoming a procurement signal for enterprise buyers. Publishing attestation documents alongside SBOMs establishes verifiable provenance for the entire artifact set.

Consumers may not verify signatures on every ingest — the infrastructure overhead is real — but the ingestion pipeline should preserve signatures, provenance documents, and attestation files even if they are not immediately verified. The cost of storing them is trivial; the cost of being unable to produce them during an audit or breach investigation is high. Verification tooling can be added later; discarded evidence cannot be recovered.

Tooling teams building SBOM management platforms should treat signature preservation as a first-class requirement, not an afterthought. Separating the SBOM payload from its accompanying provenance and attestation breaks the chain of custody.

Policy and audit teams should be aware that SLSA provenance levels are increasingly appearing in procurement requirements. CISA’s Secure by Design guidance and the NIST Secure Software Development Framework (SSDF) both reference build integrity practices that SLSA levels operationalize.

PURL

A PURL (Package URL) is a standardized way to identify a software package in a format that is consistent across ecosystems. Instead of relying only on a human-readable name, a PURL captures enough structure to make automated matching more reliable across package managers, repositories, and vulnerability databases.

A typical PURL includes the package type, namespace, name, version, and optional qualifiers or subpath information. For example, a Maven package might be represented in a way that clearly distinguishes it from the same package name in a different ecosystem. This reduces ambiguity and helps tools correlate SBOM entries with advisories, registries, and dependency data.

PURLs are especially useful in SBOM workflows because they act as a bridge between component names and machine-readable identifiers. They improve lookup precision, make dependency analysis more repeatable, and help downstream consumers map SBOM entries to known packages in vulnerability or compliance systems.

In practice, PURL is not a replacement for the SBOM itself. Instead, it is one of the key identifiers that make SBOM data more actionable, especially when combined with component name, version, supplier, and dependency information.