CycloneDX vs SPDX: Choosing an SBOM Format for Regulatory Compliance (2026 Edition)
| Interlynk
An engineering and compliance guide to the two SBOM formats, CycloneDX and SPDX, covering current versions, ISO and ECMA certification, tooling maturity, and how to pick the right one.
Who is this for?
A regulator, a customer, or your own security team asks for a software bill of materials. Before you pick a tool, you have to pick a format. The two that matter are CycloneDX and SPDX, and nearly every framework that requires an SBOM accepts either one. That is what makes the choice yours: it comes down to your tooling and the people who will actually read the file.
This guide compares the two as they stand in 2026. Current versions, what each was built for, certification status, how mature the surrounding tools are, who maintains each standard, and how you can help shape either one. It does not pick a winner. For most regulated teams both formats are viable, and plenty of organizations now produce both. What follows is the detail to decide which fits your situation, using this year's facts instead of version numbers that were right two years ago.
The short version
CycloneDX is an OWASP flagship project and now an Ecma International standard, built around application security and supply chain risk. SPDX is a Linux Foundation project and an ISO/IEC standard, built around license compliance and broad supply chain transparency. They express the same core inventory, both carry purl and CPE identifiers, and most of the feature gaps people remember between them have closed. What still separates them is emphasis, governance lineage, and the surrounding tools.
Here is the whole comparison on one screen before the detail:
CycloneDX | SPDX | |
|---|---|---|
Steward | OWASP + Ecma TC54 | Linux Foundation (+ OMG) |
Standard | ECMA-424 (1st & 2nd Ed.) | ISO/IEC 5962:2021 |
Current version | 1.7 (Dec 2025) | 3.0.1 (3.1 in RC) |
Origin / focus | 2017, security-first | 2010, license-first |
Data model | Flat, component-centric | Element-and-relationship graph |
VEX support | Native, mature tooling | Security profile, newer |
License detail | Good | Deep, file-level |
Identifiers | purl, CPE | purl, CPE |
Best-known consumer | Dependency-Track, SCA/VEX tools | Legal review, GitHub, OSPO |
Treat the rest of this guide as the footnotes to that table.
Versions and Features
Versions matter here. The regulatory and security capabilities people argue about arrived in specific releases, and citing the wrong one is the quickest way to decide on stale information.
CycloneDX is at 1.7, released in October 2025 and adopted as ECMA-424, 2nd Edition that December. It is the last release in the 1.x line and stays backward compatible with 1.4 through 1.6. Across that line, CycloneDX grew from a software SBOM format into a general bill of materials standard: hardware (HBOM), services (SaaSBOM), machine learning models (ML-BOM), cryptography (CBOM), and formal attestations (CDXA). Version 1.6 brought the Cryptographic Bill of Materials and CycloneDX Attestations. Version 1.7 added citations for verifiable provenance, patent and patent-family metadata, distribution constraints expressed as Traffic Light Protocol markers, and a wider cryptography registry. An API-first 2.0 is the next major step the project has signaled.
SPDX is at 3.0.1, part of the 3.0 line that shipped in April 2024, with a 3.1 release candidate underway. SPDX 3.0 rebuilt the foundation. It moved to an element-based model, where packages, files, snippets, and other elements each stand on their own and connect through relationships. That handles complex systems better than the document-centric 2.x design. It also introduced profiles, so a producer can include only the parts of the standard a given use case needs. The profiles cover core concepts, software, licensing, security, build, AI, dataset, and extension data, and the 3.1 candidate pushes into safety, hardware, and services. For regulatory work, the Security profile is the one to watch, because that is where SPDX finally got native vulnerability and VEX support that 2.x never had.
A nuance that trips people up: SPDX 2.3 is still everywhere, because a lot of tooling, including several Maven and build-system plugins, still emits it. You will run into 2.2.1, 2.3, and 3.0.1 in the wild, and they do not carry the same capabilities. CycloneDX shows less of this drift, thanks to its backward-compatibility promise across 1.x.
Here is the version landscape you will actually encounter, and what each one means:
Version | Released | Standard status | Why it still matters |
|---|---|---|---|
SPDX 2.2.1 | 2021 | ISO/IEC 5962:2021 | The version the ISO number actually codifies |
SPDX 2.3 | 2023 | Pre-3.0 | Still widely emitted by build tooling |
SPDX 3.0.1 | 2024 | Latest; ISO update planned | Element model + profiles, native VEX |
CycloneDX 1.6 | Jun 2024 | ECMA-424, 1st Ed. | Introduced CBOM and Attestations |
CycloneDX 1.7 | Dec 2025 | ECMA-424, 2nd Ed. | Latest 1.x; citations, patents, crypto |
Certification and standardization status
For a regulatory reader this is often the part that counts most. A formally recognized standard is easier to defend in an audit or a submission.
SPDX got there first. It was published as ISO/IEC 5962:2021 by ISO/IEC JTC 1, the joint technical committee of the two international standards bodies. One detail behind that headline matters more than any other fact in this guide:
The ISO standard codifies SPDX 2.2.1, not the current spec. SPDX 3.0.1 and the 3.1 candidate are developed in the open under the Linux Foundation, with the Object Management Group in the review loop, and the plan is to submit them to ISO as an update. Until that lands, when a requirement cites "ISO/IEC 5962:2021," it is naming 2.2.1, not 3.0.
CycloneDX went through Ecma International instead. Version 1.6 was ratified as ECMA-424, 1st Edition in June 2024; version 1.7 became the 2nd Edition in December 2025. The work happens in Ecma Technical Committee 54, jointly with the OWASP community, and the standard ships under a royalty-free patent policy. CycloneDX is also an OWASP flagship project, the label OWASP reserves for its most mature, widely adopted work.
Both paths produce a real, recognized open standard. The difference is the body behind it: SPDX carries the ISO/IEC name that a lot of enterprise and government procurement references directly, while CycloneDX carries Ecma recognition plus OWASP flagship status that security teams trust. As for the regulations themselves, none currently mandates one format over the other:
Framework | Format requirement | What it means for you |
|---|---|---|
US (CISA / EO 14028) | Both named acceptable | Either is defensible; check the consumer |
EU Cyber Resilience Act | SBOM required, format open | Pick to fit your tooling and customers |
FDA (medical devices) | Machine-readable; both pointed to | Confirm the version and encoding expected |
The catch shows up in every row: version and serialization. Regulators and their tooling care which version and which encoding you send, and submissions have been bounced over a format or encoding mismatch even when the format family was fine.
What each format was built to do
Start from whoever reads the file. That decides most of it.
SPDX began in 2010 as a way to communicate open source license information consistently between organizations, and that origin still shows. Its real strength is precise, file-level license and copyright documentation, the kind of audit trail legal review, procurement, M&A due diligence, and open source program offices live on. SPDX also maintains the SPDX License List, the standard set of identifiers like MIT and Apache-2.0 that the whole industry uses, CycloneDX included. When legal and compliance are the main readers, SPDX is the natural baseline.
CycloneDX began in 2017 inside OWASP, security-first. Its strength is carrying security context with the inventory: a dedicated vulnerabilities structure, native VEX, dependency relationships, and the wider xBOM family for cryptography, services, and ML systems. When product security, vulnerability management, or incident response are the main readers, and when VEX is how you cut unreachable-CVE noise, CycloneDX drops straight into that workflow.
Here is the 2026 update worth internalizing: the old "CycloneDX for security, SPDX for licensing" line is now only half right. The two have converged on the core inventory, even though their centers of gravity still differ:
SPDX 3.0 added a Security profile with native vulnerability and VEX support, narrowing CycloneDX's long-standing security lead.
CycloneDX added richer license and patent metadata across 1.5 through 1.7, narrowing SPDX's licensing lead.
Both now reach well beyond software, into hardware, services, AI/ML, and cryptographic inventories.
The shorthand still points you in the right direction, but do not treat it as a hard boundary.
Tooling maturity
A format is worth only as much as the tools that read and write it, and this is where the picture gets mixed. It is a big reason dual-format output caught on.
Generation is rarely the deciding factor anymore, since the most widely used open source generators emit both natively. The split is downstream. CycloneDX runs deeper in security tooling: OWASP Dependency-Track is built on it, and most vulnerability-management and VEX-aware triage systems read it without complaint. SPDX runs deeper in license-compliance tooling: established legal-review and open source compliance workflows treat it as primary, and GitHub will generate SPDX straight from a repository's dependency graph.
Then there is version lag. SPDX 3.0 support is still catching up, because 3.0 was a big model change and much of the installed base still produces 2.3. CycloneDX's 1.x backward compatibility means a 1.7 producer and a 1.6 consumer usually just work. A 2025 academic analysis of the open source SBOM tool ecosystems found measurable differences in how the two communities handle tooling issues, with faster average issue-resolution times on the CycloneDX side. Read that as a signal about ecosystem responsiveness, not a verdict on the formats.
Most mature teams land in the same place: generate both. Dual output is cheap with modern tooling, converters run in both directions, and producing both means nobody downstream can ask for the one you skipped. One warning, though. Converting between the formats can drop data, so when you need both, generate each from real build metadata rather than converting one into the other afterward.
Communities and governance
If you are going to lean on a format for years, who maintains it, and how, is not a side note. It tells you how the standard will move and whether you get a say.
SPDX is an open source project under the Linux Foundation, built by a grass-roots mix of software, systems, and tool vendors alongside foundations and integrators. The work splits across technical, legal, and outreach teams, with a monthly general call and a published governance model. The 3.0 effort tightened that governance and brought the Object Management Group into the review of the model and spec, which is part of how SPDX keeps its ISO alignment.
CycloneDX is governed jointly by the OWASP Foundation and Ecma International's Technical Committee 54. OWASP joined Ecma to give CycloneDX a formal international home without giving up its open development model. The spec lives on GitHub, the schemas are the official reading of the standard, and the JSON Schema is the reference implementation. The royalty-free patent policy comes with the Ecma arrangement.
Neither standard is controlled by a single company, and neither is a closed spec you receive from a vendor and cannot touch. For something you are betting compliance on, that independence is the point.
How to get involved
Choosing an open standard means you are not stuck as a passive consumer. If neither format quite covers your regulatory need, the path to fixing that is open, and the entry points are concrete:
CycloneDX | SPDX | |
|---|---|---|
Home | OWASP + Ecma TC54 | Linux Foundation project |
Where work happens | Ecma-TC54 and CycloneDX GitHub repos | SPDX GitHub repos + mailing lists |
How to contribute | Issues/PRs on the spec, join core or domain working groups, take part in TC54 | Join the technical, legal, or outreach team; attend the monthly general call |
Front door | cyclonedx.org | spdx.dev/participate |
Worth knowing | Proposals must keep backward compatibility | The legal team is where license precision gets settled |
Either way, a regulated organization can put a specific requirement in front of the people who maintain the standard, instead of waiting on a vendor to decide it is worth supporting.
Making the call: which SBOM format to choose
Decide by who reads the file and why. Three situations cover most teams:
Start with SPDX if your driver is license compliance, legal audit trails, procurement, or a requirement that names ISO/IEC 5962 outright. Then confirm the version it actually wants, because the ISO number still maps to 2.2.1 while the live spec is 3.0.1.
Start with CycloneDX 1.7 if your driver is security operations, vulnerability management, VEX-based triage, or you need the wider xBOM types like a cryptographic bill of materials for post-quantum readiness.
Produce both if you sell into several regulated markets and do not control which format a given customer or agency will ask for. Generate each from real build data rather than converting, and version each output on purpose.
Whatever you pick, the format is the durable part of the decision. CycloneDX and SPDX are both open, internationally recognized standards with diverse communities you can join. What will matter more to your auditors is the version and serialization you ship, and the workflow that consumes the file, not the logo on the schema.
Related reading
From SCA to SBOM: A Practical Guide to Migrating — why an SBOM-first workflow can replace a standalone scanner, and how to make the switch without a coverage gap.
SBOM Strategy & Attestation for OSS Projects: A 2026 Best-Practices Guide — picking a canonical format, automating generation, and signing what you produce.
The State of SBOM Generation for C/C++: 2026 Edition — why deriving an SBOM from the build, not the manifest, matters most in embedded.
SBOM, SOUP, COTS, and OTS in Medical Device Software — how format and version choices play out under FDA 524B and QMSR.
Continuous SBOM Monitoring — what happens after you generate the file, and why a static SBOM goes stale.
See your SBOM done right
Interlynk automates SBOMs, manages open source risks, monitors suppliers, and prepares you for the post-quantum era, all in one trusted platform. Generate CycloneDX or SPDX, validate against the standard your customers and regulators expect, and keep every output current as your dependencies and the specifications evolve.
Trusted by security and compliance teams at 100+ regulated companies.
References and further reading: SPDX (spdx.dev) and ISO/IEC 5962:2021; CycloneDX (cyclonedx.org) and ECMA-424; CISA SBOM resources (cisa.gov); the FDA premarket cybersecurity guidance; and the OWASP and Linux Foundation project pages for participation details.