CycloneDX vs SPDX: the two SBOM formats, compared

CycloneDX and SPDX are the two Software Bill of Materials (SBOM) data formats that regulators and standards bodies most commonly name by name. CycloneDX describes itself on its own site as "a full-stack Bill of Materials (BOM) standard that provides advanced supply chain capabilities for cyber risk reduction," and is maintained as an OWASP Flagship Project jointly with an Ecma International technical committee. SPDX describes itself as "an open standard for communicating software bill of material information, including provenance, license, security, and other related information," run as "an open source project hosted by the Linux Foundation." Neither format is legally mandated by name in the CRA or the CISA-led Minimum Elements document — both are simply named as acceptable, widely-used choices — so the practical question for a device maker is usually which one a given customer, tool or compliance workflow expects, not which one is "correct."

Where each format came from

SPDX is the older of the two. Specification development began in February 2010 inside a Linux Foundation work-group, split across technical, legal and outreach sub-groups; the first version (1.0) launched in August 2011, focused on package-level license documentation. The format's license-compliance roots run deep — SPDX's own license list and license-expression syntax remain one of its most widely used parts outside pure SBOM use cases. SPDX reached ISO/IEC 5962:2021 status in August 2021, formally making it "the international open standard for security, license compliance, and other software supply chain artifacts," and SPDX 3.0.0 shipped in April 2024 with a broadened data model.

CycloneDX grew out of the OWASP ecosystem, originally built to support dependency-analysis tooling such as OWASP Dependency-Track, and is listed today as an OWASP Flagship Project — OWASP's highest project maturity tier. Its specification has since been formalized as the international standard ECMA-424 through Ecma International's Technical Committee for Software & System Transparency (TC54), which cyclonedx.org states now jointly drives "the continued advancement of the specification" together with the OWASP Foundation.

What each format is built to describe

SPDX's strength remains precise license and provenance metadata per component — useful for legal/compliance review of open-source usage. CycloneDX's own site emphasizes a broader family of bill-of-materials types beyond pure software composition: SaaSBOM for service dependencies, CBOM for cryptographic assets, HBOM for hardware, AI/ML-BOM for model supply chains, and VEX for stating whether a known vulnerability in a component is actually exploitable in the shipped product — a distinction that matters a great deal to a device maker trying to triage which CVEs in a dependency actually need a patch. OWASP's project page states CycloneDX tooling is "compatible with over 260 tools across 20+ programming languages."

Where this sits next to SBOM rules device makers actually face

Neither the CRA's Annex I SBOM requirement (see our firmware SBOM guide) nor the 2026 CISA/NSA/FBI-led Minimum Elements document (see our SBOM Minimum Elements guide) mandates one specific data format by name. The Minimum Elements document instead names SPDX and CycloneDX together as the two formats "currently widely used by software ecosystem stakeholders" under its Machine-Processable Data practice, leaving the choice to the organization producing the SBOM. In practice, many open-source SBOM generation tools (Syft, Trivy and others) can emit both formats from the same underlying scan, so the real-world decision is usually driven by what a specific customer's or regulator's downstream tooling can ingest rather than by a hard legal requirement.

A workable starting point

1. Check what your largest customers or regulators actually request before standardizing on one format — some procurement processes are built around SPDX's license fields, others around CycloneDX's VEX workflow.
2. Generate both from the same scan where tooling allows it, rather than maintaining two separate SBOM pipelines by hand.
3. If vulnerability triage (not just license compliance) is the priority, lean toward CycloneDX's VEX support to communicate exploitability status alongside the component list.
4. Revisit the choice as the 2026 Minimum Elements' Machine-Processable Data practice gets adopted downstream — both formats continue to evolve (SPDX 3.0.0, CycloneDX's growing BOM family) and tooling support shifts accordingly.

SoftWSP's firmware security work produces SBOMs from binary analysis in the format your customers and compliance workflows actually need: see device & firmware security services.

This guide summarises the public CycloneDX and SPDX project sites and CISA's 2026 Minimum Elements resource page; it does not constitute legal advice.