SPDX vs CycloneDX: which SBOM format should engineers pick?

Pick the format your consumers ask for, and be ready to emit both. SPDX is an ISO/IEC standard from the Linux Foundation with deep licensing and provenance data. CycloneDX is an Ecma standard from OWASP with broad support for security use cases and several bill-of-materials types. Both satisfy NTIA's minimum elements.

Cheat sheet

SPDX

• Steward: a Linux Foundation project.
• Standard: ISO/IEC 5962:2021.
• Version noted: SPDX 3.0.0, April 2024.
• Serializations: tag:value, RDF, JSON, YAML and spreadsheet (v2.3.1).
• Strengths: licensing, provenance and a long record in compliance work.

CycloneDX

• Steward: the OWASP Foundation and Ecma International (TC54).
• Standard: ECMA-424.
• Version noted: 1.7, released 21 October 2025.
• Serializations: JSON, XML and Protobuf.
• Strengths: security use cases, VEX and several BOM types.

Versions and dates are what each project's own pages state as of 18 October 2026. Check them before you pin a version in a contract.

What did NTIA require?

NTIA's 2021 minimum elements report lists baseline data fields that include supplier name, dependency relationship, author of SBOM data and timestamp. It names SPDX, CycloneDX and SWID tags as formats that can carry them. So for the US federal context, either format passes the data-field test. The choice is about everything else.

When does SPDX fit better?

SPDX grew out of license compliance work, and it shows. If legal or open source program offices consume your SBOM, SPDX license expressions and the SPDX License List give them a shared vocabulary. SPDX 3.0 added profiles for security, build, dataset and AI use.

It also has the longest list of serializations in the v2.3.1 conformance page, which helps when a downstream tool only reads one of them.

When does CycloneDX fit better?

CycloneDX describes itself as a modular, extensible framework for supply chain transparency. Its specification covers software, SaaS and hardware bills of materials, and its object model includes cryptographic assets and machine learning models. It also describes vulnerability and VEX use cases, which matters if you want to publish "affected" or "not affected" statements alongside the inventory.

Its three serializations are JSON, XML and Protobuf.

What trips people up?

Version drift. A tool that writes CycloneDX 1.4 may not carry fields a consumer expects from 1.6 or 1.7. State the version in your delivery notes.

Empty fields. Both formats can validate while saying very little. A file with component names but no versions or suppliers passes a schema check and fails a human reader.

Mixed expectations. Procurement documents sometimes ask for "an SBOM" without naming a format. Ask. Generating both from one inventory is cheap if your tooling supports it.

How do the two differ in structure?

SPDX models a document with packages, files and relationships between them, which suits describing how a release was assembled. CycloneDX models a bill of materials with components, services and dependencies, plus fields for vulnerabilities and their status. The practical result is that the same inventory can be written in either format, but each format has fields the other lacks.

Because of that, test the exact output with the exact consumer. A format that validates against its schema can still lose meaning when a downstream tool reads it, and the only reliable check is an import test on the real system.

What to do

1. Ask each consumer which format and version they ingest.
2. Generate from one inventory, so the two outputs never disagree.
3. Validate against the published schema in CI.
4. Check the minimum NTIA fields are populated, not just present.
5. Store each SBOM with the build it describes, with the timestamp.
6. Re-check format versions twice a year.

Quick check

Sources

• NTIA: The Minimum Elements For a Software Bill of Materials (PDF)
• SPDX: About
• SPDX 2.3.1 specification: Conformance
• CycloneDX: Specification overview

Last reviewed: 18 October 2026.