SPDX vs CycloneDX SBOM formats
| Dimension | SPDX | CycloneDX |
|---|---|---|
| Steward | Linux Foundation (SPDX project). | OWASP Foundation (CycloneDX project). |
| ISO standard | ISO/IEC 5962:2021. | ECMA-424 (2024); under ISO/IEC review. |
| Primary use case | Software supply-chain compliance and license tracking. | Application-security and vulnerability management. |
| Native serializations | Tag-Value, JSON, YAML, RDF, XML, spreadsheet. | JSON, XML, Protocol Buffers. |
| Format selection | Machine-readable option; confirm content and version support. | Machine-readable option; confirm content and version support. |
| Vulnerability data (VEX) | Supports CSAF VEX externally; SPDX 3.0 adds an in-document VEX profile. | Native VEX support since v1.4 (CycloneDX-VEX). |
| Cryptographic / ML-BOM | Profiles emerging in SPDX 3.x. | Mature CBOM and ML-BOM extensions. |
| Hardware (HBOM) | Limited; planned in 3.x. | Supported via HBOM extension. |
| Tooling | Strong in build-time license scanners (FOSSology, ORT, Tern). | Strong in CI security tools (Dependency-Track, Anchore, Snyk, Syft). |
Which format should you choose?
Pick a machine-readable format your build tools produce accurately and your team can verify. Check component content, provenance, relationships, and release linkage rather than infer completeness from the file extension.
- Choose CycloneDX if your team runs security scanners in CI, plans to publish VEX statements, or needs to describe cryptographic libraries or AI models in the same file.
- Choose SPDX if open-source license compliance already drives your process, your customers or suppliers deliver SPDX, or you want an ISO-published format for procurement.
- Confirm output requirements. If you convert formats, check for lost fields and preserve provenance and review records. Neither format promises submission acceptance.
SBOM content recommended in the FDA guidance
Review inventory content independently of format. For each software component, the FDA's premarket guidance recommends baseline data elements (supplier, name, version, unique identifier, dependency relationships, author, and timestamp) plus two items many generated SBOMs leave out:
- Level of support: whether the supplier still maintains the component.
- End-of-support date: when maintenance stops, or a statement that it is unknown.
Review known vulnerabilities against the device context and define how the inventory is maintained across releases. Unknown supplier dates remain unknown pending supplier response. See the 8 deficiencies ranked from real FDA letters.
Common mistakes in either format
- Listing only the application layer and leaving out the operating system, bootloader, firmware libraries and third-party chip firmware.
- Missing identifiers (CPE or PURL), which makes vulnerability matching unreliable. See CPE vs PURL.
- Generating the SBOM once for the submission and never updating it for new releases.
- Mismatched versions between the SBOM, the software release, and the vulnerability report.