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. |
| FDA acceptance | Explicitly named in FDA premarket cybersecurity guidance. | Explicitly named in FDA premarket cybersecurity guidance. |
| 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 the format your build tools already produce most accurately. The FDA reviews what is in the SBOM, not which format holds it, so a complete CycloneDX file beats an incomplete SPDX file every time.
- 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.
- Either works for an FDA submission. Many teams keep one master format and convert on request, because hospital buyers sometimes ask for the other one.
What the FDA looks for, whatever the format
The format is the easy part. Most SBOM deficiencies come from missing content. For each software component, the FDA's premarket guidance expects the 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.
Reviewers also expect a list of known vulnerabilities in those components with an assessment of their impact on the device, and a plan to keep the SBOM current after clearance. In the 10 FDA letters we analyzed, SBOM problems appeared in 9. 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.