CycloneDX and SPDX: choosing an SBOM format

CycloneDX and SPDX are the two established formats for software bills of materials. CycloneDX came out of the application security community and is now an ECMA standard; SPDX originated in open-source licence compliance and is an ISO standard. Both are machine-readable, both are widely tooled, and both are accepted by the major buyers who ask for SBOMs.

Because both are legitimate, the choice is practical rather than doctrinal. What matters is which one your build tooling emits without extra work, which one your customers ask for by name, and whether the parts of the format you actually need are supported by the tools on both sides. Conversion between them exists and is imperfect at the edges, so choosing what your ecosystem already speaks avoids a class of problems entirely.

CycloneDX and SPDX: where the two differ

• Origin and centre of gravity: CycloneDX for security use cases, SPDX for licence and compliance use cases. Both now cover both, but the depth reflects the history.
• Licence expression: SPDX carries a formal licence expression syntax that is widely reused elsewhere, including inside CycloneDX documents.
• Security extensions: CycloneDX includes vulnerability and exploitability structures natively, which suits teams treating the SBOM as a security artefact.
• Beyond software: both have extended towards hardware, services and machine learning components, at different paces.
• Serialisation: both offer JSON, which is what almost everything consumes in practice.

Pick one, emit both if asked

The workable position is to standardise internally on whichever your pipeline produces most reliably, and to generate the other on request rather than maintaining two by hand. Customers rarely insist once they see a valid document in the other format, and where a contract does specify one, generating it at build time from the same dependency graph is a configuration change rather than a project.

Validate the file, do not just produce it. Both formats have schemas and validators, and an SBOM that fails validation will be rejected by an automated ingestion pipeline without a human ever reading it — which is exactly the scenario a customer’s security team has set up.

Completeness matters more than format

A well-formed document listing forty per cent of the dependency tree is worse than a plainer one listing all of it, because it invites false confidence. The common gaps are the same regardless of format: transitive dependencies, components pulled in by build scripts, vendored source, and anything installed into a base image. Test your output against a known application before trusting it — count the components and compare to what the package manager reports.

Keeping the documents

Ettex Sheets holds the component inventory in a readable form alongside the machine-readable file, so a person can answer a question without a tool; Ettex Records keeps the generated documents per release and format with their validation results; and the artefact itself is covered in sbom, with the obligations that drive it in sbom requirements.

Plainly: this is records and spreadsheets, not an SBOM generator. Generation belongs in the build pipeline with a purpose-built tool; what this covers is choosing sensibly and keeping what was produced.