SBOM Guide: SPDX, CycloneDX and VEX

Most organisations can now produce a software bill of materials, but far fewer can answer the question an SBOM exists for: are we affected by this vulnerability, in which products, and what are we doing about it? An SBOM is a machine-readable inventory of the components in a piece of software and how they relate. On its own it is a static list; it becomes useful only when it is accurate, complete enough, shared with the people who need it, and joined to vulnerability data and VEX statements. This guide covers the two main formats (SPDX and CycloneDX), the NTIA 2021 minimum elements and the 2026 CISA update, SBOM types, generation, VEX, sharing and consumption, vulnerability correlation, quality measurement and the regulatory drivers. It is written for product security teams that produce SBOMs and for security, procurement and vulnerability management teams that consume them.

Key takeaways

• An SBOM is an inventory, not a vulnerability report. NTIA recommended that vulnerability data be tracked in separate data structures from the SBOM; VEX documents carry the "affected or not" answer.
• Pick a format, not a fight. SPDX 3.0.1 and CycloneDX 1.7 both meet the minimum elements; most tools read and write both, and the real differences are in VEX, licensing depth and ecosystem support.
• The baseline moved in 2026. CISA and 17 co-authoring agencies published the 2026 Minimum Elements, replacing the NTIA 2021 list and adding component hash, licence, tool name and generation context.
• When an SBOM is generated matters as much as how. Source, build, analysed and runtime SBOMs see different things; label the type so consumers know what is missing.
• Value comes from consumption. Ingest supplier SBOMs, correlate them with OSV and CVE data, apply VEX, and measure how fast you can answer "are we affected?".

SBOM, VEX, provenance and VDR: what each artefact does

Teams often expect an SBOM to do jobs that belong to other documents. Keep the artefacts separate and link them.

An SBOM would not have revealed the tampered SolarWinds build, because the malicious code was inserted during the build and the component list looked normal; that is a provenance problem. See the SolarWinds compromise and the SLSA and Build Provenance Guide.

Formats: SPDX, CycloneDX and SWID

NTIA named three formats that satisfy the automation requirement: "The SBOM must be conveyed across organizational boundaries in one of these interoperable formats." In practice SPDX and CycloneDX dominate; SWID tags (ISO/IEC 19770-2) identify installed software and are rarely used as full SBOMs.

• Choose by consumer: if a regulator, customer or platform specifies one, produce that. If not, produce what your vulnerability management platform ingests natively, and convert on request.
• Watch version skew: SPDX 3.x is a different model from 2.x, and many consumers still expect SPDX 2.3 JSON. Confirm the version your consumers can parse before switching.
• Identifiers matter more than format: a Package URL (purl) such as pkg:npm/[email protected] or a CPE on each component is what lets a consumer match it to vulnerability data. OpenVEX recommends purls for the same reason.

Minimum elements: NTIA 2021 and the CISA 2026 update

NTIA's July 2021 report defined three categories of minimum elements: data fields, automation support, and practices and processes. At the end of July 2026 CISA, with 17 co-authoring agencies including NSA, FBI, ASD's ACSC, BSI, ANSSI and NCSC-NZ, published the 2026 Minimum Elements, which replace the NTIA baseline. CISA's own page and PDF could not be read for this guide, so the 2026 column is taken from the August 2025 public comment draft and from co-author and trade reporting; check the final PDF before using it in a contract.

Help Net Security also reports a digital signature field so recipients can confirm an SBOM has not been altered, and that the elements apply "to SBOMs for all software". The NCSC-NZ announcement states that components "can include traditional software, firmware, AI systems, and SaaS". AI-specific fields are left to separate G7 AI SBOM guidance; see the AI Supply Chain and AI-BOM Guide.

The NTIA practices still apply and are where most programmes fall short:

• Frequency: "If the software component is updated with a new build or release, a new SBOM must be created."
• Depth: top-level components at minimum, transitive dependencies wherever possible.
• Known unknowns: state explicitly where the dependency graph is incomplete; otherwise consumers should assume it is.
• Distribution and access control: make SBOMs available in time; "If access control is desired, the terms must be specified."
• Accommodation of mistakes: consumers should tolerate good-faith errors and suppliers should publish corrections.

SBOM types and when to generate

SPDX 3.0.1 adopts the six types from CISA's April 2023 "Types of Software Bill of Material (SBOM) Documents", and one SBOM can carry several. The type tells consumers what the inventory can and cannot see.

Decision guidance: producers should treat the build SBOM as the release record, because it is tied to the artefact and its hash. Consumers buying closed-source products, and teams with legacy binaries, rely on analysed SBOMs (software composition analysis for binaries), which work without supplier co-operation but are less precise. Large estates add deployed SBOMs so a new vulnerability can be traced to hosts, not just products.

Generating SBOMs

The tools below are documented examples, not recommendations. All three produce both main formats.

• Syft: generates SBOMs from container images, filesystems and archives, for example syft <image> -o spdx-json=./spdx.json -o cyclonedx-json=./cdx.json. It can create signed SBOM attestations using in-toto and is designed to pair with the Grype scanner.
• Trivy: trivy image --format cyclonedx --output result.json alpine:3.15 or trivy fs --format spdx-json. Its CycloneDX output excludes vulnerabilities unless --scanners vuln is added, which keeps the inventory and the findings apart.
• cdxgen: builds CycloneDX (default spec 1.7) across many language ecosystems, can emit SPDX 3.0.1 JSON-LD, adds evidence with --evidence, and signs and verifies BOMs with JSON Signature Format (cdx-sign, cdx-verify).

Practical rules for producers:

• Generate in CI from the artefact you ship, not from a developer laptop, and record the tool name, version and generation context.
• Include hashes and purls for every component; without them consumers fall back to fuzzy name matching.
• Sign the SBOM or attach it as an attestation to the artefact digest. The signing identity is a machine credential: issue it through workload identity federation or keyless signing rather than a long-lived key in a CI variable. See the CI/CD Pipeline Identity Security Guide.
• Diff each release against the last: an SBOM diff that shows a new dependency, a changed maintainer namespace or a component with no source repository is a cheap supply chain review signal.

VEX: telling consumers what actually matters

A typical container image produces dozens of CVE matches, most of which are not exploitable in that product. VEX lets the supplier state the status per vulnerability and product so consumers can suppress noise with an audit trail. NTIA pointed to CSAF for VEX; OpenVEX was designed to meet CISA's Minimum Requirements for VEX (April 2023).

The five standard justifications in OpenVEX are component_not_present, vulnerable_code_not_present, vulnerable_code_not_in_execute_path, vulnerable_code_cannot_be_controlled_by_adversary and inline_mitigations_already_exist. The spec requires a not_affected statement to "include either a status justification or an impact_statement", and treats VEX as a sequence of statements, each overriding and enriching the previous ones.

• CSAF VEX: the VEX profile (csaf_vex) of the OASIS CSAF 2.0 standard (November 2022). Best where you already publish CSAF advisories; distribution can use provider-metadata.json and TLP labels.
• OpenVEX: a minimal JSON format (@id, author, timestamp, version, statements) that is easy to generate in CI and attach as an attestation.
• CycloneDX VEX: vulnerability analysis inside a CycloneDX BOM or, more usefully, a separate VEX BOM linked to the SBOM so it can be updated without reissuing the inventory.

Consumers can apply VEX at scan time. Trivy, for example, accepts CycloneDX, OpenVEX and CSAF files with --vex and drops findings marked not_affected, matching on purl. Its documentation warns that the feature is experimental and that some purl matching rules "are not formally defined within the current official PURL specification", so test matching before trusting suppression.

Sharing, ingesting and correlating

NTIA requires SBOMs to be available "in a timely fashion to those who need them". The EU CRA does not require public SBOMs; access can be limited to customers or authorities.

• Delivery: publish alongside the release in a customer portal, attach to the container image in the registry as an attestation, or provide on request under NDA. State the access terms.
• Ingestion: validate the schema, check the signature, record the generation context, and load the SBOM into an analysis platform keyed by product and version. OWASP's Top 10:2025 names Dependency-Track as one option for continuous SBOM analysis.
• Correlation: match components by purl to OSV, which aggregates the GitHub Advisory Database, PyPI, Go, RustSec and OSV-converted NVD data, and by CPE to NVD.
• Procurement: write SBOM delivery into contracts: format and version, minimum elements, delivery per release, VEX for critical CVEs within an agreed time, and a named contact.

Why false positives happen

• Name-based matching: components without purl or CPE are matched by name, so unrelated packages with the same name collide.
• Backported fixes: Linux distributions patch older upstream versions; version-range matching against upstream advisories flags fixed packages. Use distribution advisories for OS packages.
• Unreachable code: the vulnerable function is never called. This is what VEX justifications exist to document.
• Stale SBOMs: scanning last quarter's SBOM against today's advisories reports components already upgraded, and misses those added since.

False negatives matter more. An SBOM missing a vendored or statically linked library gives a confident "not affected" that is wrong, which is why known unknowns must be declared. During the XZ Utils backdoor response, teams with current deployed SBOMs could query for the affected xz versions 5.6.0 and 5.6.1 instead of surveying hosts by hand.

Regulatory and policy drivers

For medical devices, the FDA guidance section V.A.4(b) adds expectations beyond the statute; see the Medical Device Security Guide. Germany's BSI TR-03183-2 is a further SBOM specification that tools such as sbomqs can check against.

Implementing an SBOM programme

1. Inventory products and pick formats: list shipped products and internal critical applications, choose one primary format per consumer, and agree identifiers (purl first).
2. Pilot build SBOMs on two or three products in CI, in report-only mode. Compare the output with lock files and a manual review to measure completeness before publishing anything.
3. Add hashes, signing and generation context, then attach the SBOM to the artefact digest. Fail the release only when the SBOM is missing or invalid, not on findings.
4. Stand up ingestion and correlation for your own and supplier SBOMs; tune matching on distribution packages before alerting anyone.
5. Start VEX with the noisiest critical CVEs, using a reviewed template so justifications are consistent and auditable.
6. Extend to suppliers through contract clauses and a delivery channel, beginning with suppliers of internet-facing and regulated products.
7. Roll back safely: if an SBOM gate blocks releases through tool errors, return it to report-only, keep generating, and fix the tool configuration; never ship without retaining the SBOM.

Small teams can get most of the value with one generator in CI, one format, and an OSV-based scanner reading the SBOM. Large organisations and regulated manufacturers need a central SBOM repository, VEX publishing, supplier intake and quality gates per product line.

Measuring SBOM quality and programme health

A valid file is not a good SBOM. Quality tools such as sbomqs score SBOMs from 0 to 10 across identification, provenance, integrity, completeness, licensing and structure, and can report against NTIA minimum elements and BSI TR-03183-2. Track:

• Coverage: percentage of releases and in-scope supplier products with a current SBOM.
• Identifier completeness: percentage of components with a purl or CPE, a version, a supplier and a hash.
• Depth: percentage of SBOMs with transitive dependencies and declared known unknowns.
• Time to answer: hours from a critical CVE's publication to a confirmed affected or not-affected list across products.
• VEX coverage: percentage of critical and high matches with a VEX statement within the agreed time.
• False positive rate: share of matches closed as not affected, trended after matching and VEX changes.

Framework mapping

Common failure patterns

• Generate and forget: SBOMs are produced for compliance and stored, but never ingested or queried, so the next Log4j-style event is still answered by grep and email.
• Source-only SBOMs for container releases: the base image and OS packages are missing, which is often where the critical CVEs live.
• Expecting an SBOM to detect malicious versions: an SBOM lists the poisoned package faithfully. It helps you find exposure after the fact, as with the Shai-Hulud npm worm, but prevention needs publisher hygiene and provenance. See the Open Source Security Guide.
• Suppressing findings without VEX: local ignore lists hide noise with no justification, no expiry and no audit trail.
• Unsigned SBOMs from an exposed pipeline: whoever controls the release path controls what ships with it, SBOM included. The Trivy supply chain attack shows how one stolen token can hand over a release path; sign SBOMs with short-lived identities and verify them on ingestion.

Practitioner checklist

• Generate a build SBOM in CI for every release and retain it with the artefact.
• Include purl or CPE, version, supplier and hash for every component, and declare known unknowns.
• Record SBOM type, tool name and generation context.
• Sign SBOMs or attach them as attestations using short-lived, workload-issued credentials.
• Ingest your own and supplier SBOMs into one platform and correlate with OSV and NVD daily.
• Publish VEX for critical and high matches, with standard justifications.
• Write format, minimum elements, delivery and VEX timelines into supplier contracts.
• Check readiness against CRA Annex I and VII if you sell into the EU, and section 524B for medical devices.
• Measure time to answer "are we affected?" and report it.

Standards and references

• NTIA: The Minimum Elements For a Software Bill of Materials (SBOM)
• NCSC New Zealand: 2026 Minimum Elements for a Software Bill of Materials (SBOM) published
• SPDX: Specification Version 3.0.1
• CycloneDX: Specification Overview
• OASIS: Common Security Advisory Framework Version 2.0
• OpenVEX: Specification
• US FDA: Cybersecurity in Medical Devices Frequently Asked Questions
• European Commission: Cyber Resilience Act

Related NHI Mgmt Group resources: Open Source Security Guide · SLSA and Build Provenance Guide · AI Supply Chain and AI-BOM Guide · Vulnerability Management Guide · CI/CD Pipeline Identity Security Guide