SBOM explained: CycloneDX, SPDX and VEX in practice

An SBOM, or Software Bill of Materials, is a machine-readable inventory of the components that make up a software product. When a critical CVE appears, a reliable SBOM helps answer which products contain the affected library, version and dependency path. Without it, teams search repositories, images and spreadsheets manually while exposure remains uncertain.

The file alone does not make software secure. It must be complete enough for its purpose, tied to a specific artefact, generated at the right stage, protected against tampering and connected to vulnerability response. CycloneDX and SPDX provide formats; VEX adds context about whether a known vulnerability actually affects a product.

What an SBOM contains

Imagine product version 4.8.2. It directly uses a web framework, database client and cryptographic library. Each has transitive dependencies. An SBOM records information such as:

• product and component name;
• supplier and author;
• exact version;
• identifiers such as Package URL (PURL) or CPE;
• dependency relationships;
• cryptographic hashes;
• licences;
• creation time and tool;
• document namespace or serial identifier.

The generation method matters. A manifest-based tool sees declared packages. A filesystem or container scanner sees installed artefacts. Build instrumentation can observe what was resolved during compilation. These views may differ, so the document should state what it describes and how it was created.

The current CISA Minimum Elements for an SBOM provides a useful baseline for data fields, automation and operational use. An organisation may require more detail for high-risk products.

CycloneDX versus SPDX

Both formats are open standards and support machine-readable component information. The right choice depends on ecosystem, consumers and workflow rather than a claim that one format is universally superior.

CycloneDX

CycloneDX originated in the OWASP community with a strong security and software-supply-chain focus. It supports components, services, dependencies, vulnerabilities, compositions, pedigree and other lifecycle data. Many security tools can generate and consume CycloneDX JSON.

It is a practical option when the main consumers are vulnerability-management, product-security and DevSecOps teams. The model can describe services and security-relevant relationships beyond a simple package list.

SPDX

SPDX is an ISO standard with strong roots in licence compliance and software-package exchange. It can represent packages, files, snippets, relationships, licences, checksums and annotations. SPDX is widely used in open-source governance and supports both licensing and security workflows.

It is often a good fit when legal, open-source programme and engineering teams need one shared representation or when customers and regulators explicitly request SPDX.

Which format should you choose?

Ask the receiving system. A valid file that no customer, vulnerability platform or procurement workflow can consume has limited operational value. Evaluate:

• formats accepted by customers and authorities;
• support in your build and scanning tools;
• ability to represent dependency relationships accurately;
• licence and security use cases;
• signing and distribution process;
• validation and conversion quality.

Supporting both formats may be reasonable if they are generated from the same authoritative build evidence. Avoid maintaining two manual inventories that drift apart.

What VEX adds

A vulnerability scanner may report that a product contains a component associated with a CVE. Presence does not always mean exploitability. The vulnerable function may be absent, unreachable, disabled or protected by another control.

VEX—Vulnerability Exploitability eXchange—communicates the product’s status for a specific vulnerability. Typical states express that the product is affected, not affected, under investigation or fixed, with a justification and action where relevant.

The CISA minimum requirements for VEX explain the core information needed for useful exchange. VEX should reduce false urgency, not conceal uncertainty. A “not affected” statement needs a defensible technical justification and must be revised if the product or evidence changes.

SBOM is not a vulnerability report

An SBOM describes composition. A vulnerability database maps identifiers and versions to known issues. VEX supplies product-specific exploitability context. These are related but distinct artefacts.

A component can be:

• present and affected;
• present but not affected for a documented reason;
• present with status still under investigation;
• absent despite a scanner’s name-based false match;
• modified or backported so version comparison alone is insufficient.

This distinction matters during a critical disclosure. Security teams need to know what exists, whether it is reachable, who owns the product and what action is planned.

Where to generate an SBOM

Generating only from a developer’s lockfile can miss operating-system packages, copied binaries, runtime plugins and changes introduced by the container base image. Scanning only a final image may lose source and dependency metadata.

A strong process combines evidence:

1. Source stage: declared dependencies and lockfiles.
2. Build stage: resolved components and build environment.
3. Container or package stage: files and OS packages in the deliverable.
4. Release stage: the SBOM tied to the exact published artefact.
5. Runtime stage: separately observed drift, plugins and deployed versions.

The release SBOM should correspond to an immutable digest. “SBOM for main branch” is not sufficient when customers run a specific image or installer.

Component identity and dependency relationships

Names are ambiguous. Include ecosystem-aware identifiers such as PURL and hashes where possible. Record namespaces, suppliers and exact versions. For internal components, create a consistent naming and version policy.

Dependency relationships are critical for triage. If a vulnerable package is transitive, the team needs to know which direct dependency introduced it and which product owns the update. A flat list makes impact analysis slower.

SBOM completeness can be expressed with composition information when the format supports it. Be honest when a subsystem, proprietary module or build stage was not analysed.

Signing, provenance and integrity

An attacker who can replace the product or SBOM can create a false sense of safety. Protect both through release controls:

• calculate and publish artefact digests;
• sign release artefacts and attestations;
• bind the SBOM to the same immutable digest;
• restrict CI identities and signing keys;
• retain verifiable build provenance;
• verify signatures before ingestion;
• log generation and publication events.

Projects such as Sigstore and SLSA provide useful mechanisms and models. Our guide to software supply-chain attacks explains why trusted build identity matters as much as package inventory.

Integrating SBOM into CI/CD

A practical pipeline can follow this sequence:

1. Resolve dependencies from locked, approved sources.
2. Build the artefact in a controlled environment.
3. Generate source- and artefact-level SBOM evidence.
4. Validate schema and required fields.
5. Scan components against vulnerability intelligence.
6. Apply a risk policy based on severity, exploitability and exposure.
7. Sign the artefact, SBOM and provenance.
8. Publish them to the release registry.
9. Import data into the product and vulnerability inventory.
10. Monitor new disclosures throughout the supported lifetime.

Do not fail every build for every historical CVE without context. Define gates for newly introduced critical issues, known exploitation and policy violations. Route existing debt into an owned remediation plan with deadlines.

Operational response to a new CVE

When a high-impact vulnerability is disclosed:

1. Query the inventory by PURL, CPE, hash and version range.
2. Identify affected products, environments and owners.
3. Verify SBOM freshness and completeness.
4. Determine whether the vulnerable code is present and reachable.
5. Check exploitation status and external exposure.
6. Publish a justified VEX status where appropriate.
7. Patch, mitigate or remove the component.
8. Rebuild and issue a new SBOM for the fixed artefact.
9. Confirm deployed versions and close the response with evidence.

This process should connect to the broader vulnerability-management lifecycle. SBOM accelerates identification; it does not make prioritisation or deployment decisions automatically.

Common SBOM implementation mistakes

A file generated once for compliance

An inventory becomes stale after the next release. Generate it for every supported artefact and monitor components over time.

No link to the product digest

If the recipient cannot determine which image or installer the document represents, the SBOM is difficult to trust. Use immutable identifiers and release metadata.

Only direct dependencies

Critical vulnerabilities frequently appear in transitive or operating-system components. Preserve the dependency graph and scan the final deliverable.

Silent conversion loss

Converting CycloneDX to SPDX or the reverse can drop fields or relationships. Validate the output and document which representation is authoritative.

Treating “not affected” as permanent

A VEX judgement depends on product version and technical evidence. Re-evaluate after dependency, configuration or code changes.

Publishing sensitive internal topology

An SBOM should be useful without disclosing unnecessary internal repository paths, credentials or confidential service architecture. Define external and internal distribution profiles if needed.

Procurement and supplier requirements

Ask suppliers for a machine-readable SBOM tied to the delivered version, update frequency, supported format, vulnerability-notification process and VEX capability. Also define retention, authenticity and delivery channel.

Receiving a file is only the beginning. Test whether it parses, contains transitive dependencies, maps to the artefact and supports an actual incident query. Include these checks in third-party risk management.

SBOM implementation checklist

• Define consumers and operational questions first.
• Select CycloneDX, SPDX or both based on interoperability.
• Generate evidence from source, build and final artefact.
• Include unique identifiers and dependency relationships.
• Tie every document to an immutable release digest.
• Validate schema, required fields and completeness.
• Sign or attest release evidence and protect CI identity.
• Import data into vulnerability and product inventory.
• Define evidence requirements for VEX statuses.
• Monitor supported releases for newly disclosed issues.
• Test the response process with a known component scenario.
• Retire SBOM records according to product support policy, not build-log convenience.

An SBOM creates value when it shortens the time from disclosure to a confident product decision. If you need to review your supply-chain controls or validate whether generated inventories match real artefacts, contact Breachroad.