Once you accept that you need a Software Bill of Materials, the next question is which format to produce it in. Two standards dominate: CycloneDX and SPDX. Both list your components; they differ in emphasis, tooling, and pedigree.
SPDX — the licensing-first ISO standard
SPDX (Software Package Data Exchange) began at the Linux Foundation to solve license compliance, and it's now an ISO/IEC standard. If your primary concern is knowing the license of every component and satisfying legal review, SPDX's data model is rich and battle-tested — it's the lingua franca of open-source license tooling.
CycloneDX — the security-first OWASP standard
CycloneDX came out of OWASP with security in mind. It carries vulnerability data, VEX statements, and component relationships as first-class citizens, which makes it a natural fit for supply-chain security and regulations like the EU Cyber Resilience Act. If your SBOM's main job is to answer "are we exposed?", CycloneDX is built for that question.
How to choose
- Security / regulatory driver (CRA, vulnerability monitoring): lean CycloneDX — VEX and vulnerability linkage are native.
- License-compliance driver: SPDX's licensing model is deeper, and its ISO status is required by some procurement processes.
- Customer mandate: just generate whichever your customer or auditor asks for.
The good news: they're convertible. Tools translate between the two, so picking one isn't lock-in. What matters far more is that the SBOM is generated automatically on every build and kept current — a stale SBOM in either format is useless.
Don't agonise over the format. Pick CycloneDX if security drives you, SPDX if licensing does — and make sure it regenerates on every release either way.
Generating a current CycloneDX SBOM and monitoring it for vulnerabilities is step one of Proofwright's CRA workflow.