Both CycloneDX and SPDX are established SBOM standards, and most modern tools read both. Pick the one your customers or regulators ask for. If nobody asks, choose the one your tooling emits best, and be ready to produce the other.
Where each comes from
CycloneDX describes itself as a modular and extensible framework for representing a broad range of supply chain information. It is developed by the OWASP Foundation and Ecma International, and its standard is ECMA-424. The overview page lists version 1.7, released 21 October 2025, with documentation in JSON, XML and Protobuf.
SPDX is an open source project hosted by the Linux Foundation. Its overview page gives the international standard designation as ISO/IEC 5962:2021. It covers provenance, license and security data, and it also publishes the SPDX License List with identifiers and expression syntax.
How they differ in practice
CycloneDX grew from application security work, and its object model reaches beyond software components to services, vulnerabilities, hardware, machine learning models and more. SPDX grew from license compliance, and its license identifiers are widely used even outside SPDX documents.
Neither is wrong for either job. Both can carry component names, versions, licenses and dependency relationships. The difference is mostly in emphasis and in how tools and procurement documents refer to them.
Format and file naming
CycloneDX documents conventionally use file names such as bom.json and bom.xml, or the patterns *.cdx.json and *.cdx.xml. Its media types include application/vnd.cyclonedx+json. For SPDX, the overview page does not name file formats, so check the specification version you target before you commit to one in a contract.
A decision rule
- Does a customer, regulator or contract name a format? Use that.
- Is your main goal license compliance? SPDX is a natural fit.
- Is your main goal vulnerability management and dependency analysis? CycloneDX is a natural fit.
- Neither? Emit one by default and keep a converter in your pipeline.
CISA describes an SBOM as a nested inventory, a list of ingredients that make up software components, and it publishes minimum elements guidance. The 2026 update replaces the 2021 minimum elements from NTIA and notes that some software, such as AI and SaaS, may need elements beyond the minimum. Either format can satisfy the shape of that guidance, but check the document itself for the field list, because the summary page does not give it.
Pitfalls
Do not treat conversion as lossless. Fields that exist in one format may have no equivalent in the other. Always diff a converted file against the original before sending it to a customer.
Do not generate an SBOM once and forget it. The inventory is only true for the build it came from. See the reading a lockfile post for where the data starts.
Where Safeguard fits
Safeguard generates and scans SBOMs, and the free scan at gold.safeguard.sh/scan accepts CycloneDX or SPDX files along with package.json and requirements.txt.
Quick check
Is one format more official than the other?
CycloneDX is ECMA-424 and SPDX is ISO/IEC 5962:2021, per their own pages. Both are recognised standards.
Can I convert between them?
Yes with tools, but check for lost fields before you rely on the result.
Sources
- CycloneDX specification overview
- SPDX overview
- CISA, Software Bill of Materials
- CISA, 2026 Minimum Elements for an SBOM
- Safeguard free scan
Last reviewed: 19 October 2026.
