SBOM formats and standards
CycloneDX and SPDX, and how to choose between them
An SBOM needs to follow a standard format to be readable by anyone other than its creator. Two formats are in practical use: CycloneDX and SPDX.
Comparison
| CycloneDX | SPDX | |
|---|---|---|
| Maintained by | OWASP | Linux Foundation |
| Standard | ECMA-424 | ISO/IEC 5962:2021 |
| Original purpose | Security analysis of components | Licence information for open source |
| File formats | JSON, XML, Protocol Buffers | JSON, YAML, RDF, tag-value |
| Beyond SBOM | VEX, VDR, HBOM, CBOM, ML-BOM, SaaSBOM | Profiles for security, licensing, build and AI (SPDX 3) |
CycloneDX
CycloneDX1 was developed within OWASP to describe software components with vulnerability analysis as the main use. Version 1.6 was adopted in 2024 as the ECMA-424 standard by Ecma International.
The format can express more than an SBOM. The same specification is used for VEX, for cryptographic assets (CBOM) and for hardware (HBOM).
SPDX
SPDX2 (Software Package Data Exchange) comes from the Linux Foundation and started as a way to exchange licence information about open source. Version 2.2.1 is the ISO standard ISO/IEC 5962:2021.
SPDX 3, released in 2024, is divided into profiles for different uses, among them security, build and AI. Most tools still mainly support SPDX 2.
Which format should you choose?
Both formats meet the requirement in the Cyber Resilience Act (CRA) for a commonly used and machine-readable format, and both can express the SBOM Minimum Elements.
The choice is usually decided by the surroundings:
- which format your build tools produce best
- which format your customers or suppliers require
- whether you need VEX in the same format, which favours CycloneDX
- whether licence compliance is the main purpose, which favours SPDX
It is possible to convert between the formats, but information can be lost because the formats do not have exactly the same fields. Preferably create the SBOM directly in the format that will be delivered.