In software and cybersecurity, knowing what’s inside your software is really important. That’s where SBOM, or Software Bill of Materials, comes in.
But here’s where it gets interesting: there are different ways to create these SBOMs, and two prominent formats often stand in the spotlight: SPDX vs CycloneDX. Both serve the same fundamental purpose of helping you understand your software’s inner workings, but they do so in their own unique ways. That’s where this comparison comes in. Read on to learn more about these two formats.
The short answer: both are now formal international standards and both satisfy US federal SBOM requirements, so neither choice is wrong. They differ in where they came from. SPDX grew out of open-source licence compliance and is the stronger record of what software is; CycloneDX grew out of application security and is the stronger record of what software exposes you to. The detail that decides it for most teams is below.
What is SPDX?
SPDX is one of the major SBOM (software bill of materials) standards for specifying the software components in a product.
It provides a standard language for software developers, buyers, and sellers to communicate the components, copyrights, licenses, and security information associated with software components in multiple file formats and the products they are creating, using, and selling.
What is CycloneDX?
CycloneDX is a standard SBOM tool for managing software development projects. It helps you track your project’s dependencies, license information, and security vulnerabilities. It also makes finding and fixing security vulnerabilities in your code manageable.
SPDX vs CycloneDx
History
SPDX was created and developed in 2010 by the Linux Foundation.’ As per the Linux Foundation, SPDX provides a standard data exchange format. In addition, it focuses on providing open-source license compliance.
CycloneDX was created in 2017 by the ‘OWASP‘ community and developed as an open-source project. It focuses on vulnerabilities and security along with open-source.
It provides vulnerability identification, license compliance, and outdated component analysis for open-source components. OWASP, ServiceNow, and Sonatype team members are core working groups.
Supported formats of SPDX vs CycloneDX
SPDX
- Historically SPDX used tag-value (.spdx), RDF, spreadsheets and later JSON, XML and YAML. SPDX 3.0 is built on an RDF-based model with JSON-LD as the primary serialisation, so if you are generating SPDX 3.x today expect JSON-LD rather than the older tag-value files.
CycloneDX
- You can represent the CycloneDX in different file formats, such as. XML, JSON, and protocol buffers and get source code on GitHub.
Features of CycloneDX vs SPDX
Neither format is simply “bigger” than the other, and claims that one only works at project scope are out of date. They lead in different places:
- CycloneDX covers more kinds of bill of materials. Beyond a software BOM it defines SaaSBOM for services, HBOM for hardware, ML-BOM for AI and machine-learning models, CBOM for cryptography, and VEX for stating whether a known vulnerability actually affects you. If your question is “what am I exposed to”, this breadth is the reason to pick it.
- SPDX goes deeper on licensing and provenance. It carries file-level and snippet-level detail, a curated licence list, and relationships between documents, packages and files. If your question is “what exactly is in this and what may we legally do with it”, that depth is hard to match.
- SPDX 3.0 narrowed the gap deliberately. It reorganised the specification into profiles, with Core plus optional Security, Licensing, Build, AI and Dataset profiles, which brings security and AI use cases into SPDX itself.
- Two practical asymmetries worth knowing. CycloneDX carries document signature and document version natively inside the document. SPDX has explicit
NOASSERTIONandNONEvalues, which let a reader tell “we do not know” apart from “we deliberately did not say” – a distinction that matters more since CISA’s 2026 guidance asked authors to make exactly that call.
The two formats side by side
More about SPDX vs CycloneDX
| SPDX | CycloneDX |
| Information about document creation: It gives information about who, how, and when created the SPDX file and associates analysis results with a particular version of the SPDX file | BOM metadata: It provides information about the manufacturer, supplier, target components, license information, and tools used to create BOM. |
| Package information: Matters that are common properties of the whole package | Components: This field outlines the inventory of first-party and third-party components |
| File information: Matters that are particular to files that may be included in packages | Services: It outlines the external APIs such as authentication requirements, endpoint URIs, trust boundary traversals |
| Snippet information: Matters that are particular to only a part of the file | Dependencies: Outlines how components depend on each other through a dependency graph that shows direct and transitive relationships |
| Licensing information: A method to capture information about licenses and refer to other licenses that are not provided in the SPDX license list | Extensions: Provides extension points to help future use cases and functionality |
| Correlation between SPDX elements: Provides details about how documents, files, and packages related to each other | |
| Annotations: Details about who reviewed SPDX files and when reviewed |
Where each standard stands today
Both formats are moving quickly, and a lot of comparison writing is pinned to versions that are now several years old. This is the current position.
SPDX
- SPDX 3.0 arrived in April 2024 and 3.0.1 in December 2024. A 3.1 release candidate was published in January 2026.
- It is an ISO standard: ISO/IEC 5962:2021. One precision point that trips people up in procurement: that ISO text describes SPDX 2.2.1, not 3.x. If a contract or policy cites ISO/IEC 5962:2021, it is naming version 2.2.1. Newer versions are intended to go to ISO as an update, but until that lands the citation and the current release are not the same thing.
- Governed under the Linux Foundation, with a long list of supporting organisations.
CycloneDX
- It is also a formal standard, via a different body: ECMA-424. CycloneDX 1.6 was ratified as ECMA-424 1st Edition in June 2024, and 1.7 became the 2nd Edition in December 2025.
- Governed jointly by the OWASP Foundation and Ecma International Technical Committee TC54.
- Tooling breadth is one of its stronger arguments: the project reports compatibility with well over 200 tools across more than 20 programming languages.
What regulators say (and do not say)
CISA’s 2026 update to the SBOM minimum elements, which replaced the 2021 NTIA guidance, names SPDX and CycloneDX as the accepted data formats. Software identification (SWID) tags dropped off that list. The practical reading for anyone selling into US federal supply chains: either format satisfies the requirement, so format choice is a technical decision rather than a compliance one.
Two changes in that 2026 guidance are worth planning for whichever format you pick. Coverage now extends to all components including transitive dependencies, with no stated depth limit, and authors are asked to distinguish information they lack from information they are withholding. The second point is where SPDX’s NOASSERTION and NONE values earn their keep, and where CycloneDX users should check how their generator represents unknowns.
So which should you use?
The formats are converging, and the honest answer is that the decision usually rests on context rather than on a feature table:
- Choose CycloneDX if your driver is security: vulnerability management, VEX statements so you can say a CVE does not affect your build, or you need bills of materials for services, hardware, cryptography or AI models. It is also the more common default in application-security tooling.
- Choose SPDX if your driver is licence compliance, open-source governance, or contracts that cite ISO/IEC 5962. Its file and snippet-level detail and its curated licence list are the deciding factors.
- Let your toolchain choose if neither driver dominates. The format your build system, scanner or vendor already emits cleanly will cost you far less than the one that looks marginally better on paper, and conversion between the two is routine, if imperfect at the edges.
- Do not assume you must pick one. Plenty of organisations publish both, because a customer or regulator asks for a specific format and generating the second one is usually a build-pipeline setting rather than a project.
The failure that actually causes problems is not choosing the “wrong” format. It is producing an SBOM once, by hand, and letting it drift out of date, so that the document describes a build you no longer ship. Whichever format you adopt, generate it automatically as part of the build.
FAQs
What are SBOM standards?
SBOM standards are guidelines that help ensure a consistent and accurate description of the components that make up a system. That can make it easier to identify and manage licenses for the various parts of a system and track down any potential issues with using specific components.
What is the main difference between SPDX and CycloneDX?
SPDX (Software Package Data Exchange) is a standard format for sharing information about software packages, while CycloneDX is a specification for creating SBOMs (Software Bill of Materials). Both aim to provide accurate and consistent information about the components that make up a system.
Which standard is better to use?
Answering this question is a little tricky. You can choose the standards depending on your specific needs. For example, if you need to share detailed information about the components in a system with humans, then SPDX is probably the better choice. However, if you need to generate SBOMs that machines can quickly process, CycloneDX will likely be a better fit.
Conclusion
In this article, we have explained SPDX vs CycloneDX. We found that both these tools are suitable for different purposes.
While SPDX is more prevalent among developers, CycloneDX is better suited for data scientists. However, both these tools are worth trying out. Thank you for your readership.