SPDX or CycloneDX: Choosing an SBOM Format You Can Actually Operate
An SBOM programme usually starts with a format argument and stalls there. The argument is avoidable. The two formats that dominate the field are both accepted by the guidance that matters, and the decision that determines whether the programme works is not which format you pick. It is whether the format you pick fits the tooling on both ends of the pipeline.
That framing is consistent with how CISA's minimum-elements work treats the question. The requirement is a machine-readable, standardised format that supports automation; SPDX and CycloneDX are named as the open, mature options.
What the two formats are
SPDX came out of the Linux Foundation and reached international standard status as ISO/IEC 5962. Its heritage is licence and compliance metadata, and its document model describes packages, files, and snippets with relationships between them. It is verbose and precise, and it supports several serialisations including JSON, XML, YAML, and tag-value.
CycloneDX came out of OWASP and was designed from the start as a bill-of-materials format for security and supply-chain analysis. It models components, services, and vulnerabilities, and it has explicit support for vulnerability exploitability exchange data. Its serialisations are JSON and XML.
A useful shorthand that circulates in the field is that SPDX reads like a legal document and CycloneDX reads like a security document. The shorthand captures the design centre of each format, and it also predicts which one fits a given consumer.
The selection criteria that change outcomes
Four questions decide the choice better than any format feature comparison.
What does the producer emit natively? If your build tooling already generates one format without a plugin, choosing the other means maintaining a conversion step. Conversion is possible and tools exist, but every conversion is a place where fields get dropped, and dropped fields are discovered during an incident rather than during the pilot.
What does the consumer ingest? A vulnerability scanner, a dependency-tracking platform, or a procurement portal may accept only one format, or may accept both but populate fewer fields from one of them. The consumer is usually the harder constraint, because the consumer is where the SBOM is supposed to create value.
Do you need vulnerability exploitability data? CycloneDX carries explicit support for VEX, which is the mechanism for stating whether a component is actually affected by a given vulnerability. If your workflow depends on suppressing non-exploitable findings, that support is a reason to prefer CycloneDX, and it is a reason to check whether your tools emit and honour VEX rather than assume it.
Does the format need to carry licence and provenance detail? SPDX's depth in licence and file-level information is a reason to prefer it where compliance and legal review are the primary consumer.
These four questions rarely produce a tie. They usually produce a clear answer from the toolchain, and the answer is often different for source components and for container images.
What the minimum elements require, regardless of format
CISA's minimum-elements guidance establishes what an SBOM has to contain to be useful: supplier name, component name, component version, other unique identifiers, dependency relationships, the SBOM author, and a timestamp, in a machine-readable format. Later revisions added component hashes and clarified that licence information should be recorded in a machine-readable way.
Both formats can express every one of those fields. That is the point. Arguing about the format before confirming that your producer populates the fields is arguing about the container before checking whether it is full.
The format that is usually right
In practice, the format question resolves like this. If your consumers are security tooling and your workflow depends on component-level vulnerability status, CycloneDX is usually the better fit. If your consumers are compliance and licence review and you need file-level granularity, SPDX is usually the better fit.
Where both are needed, most mature producers emit both, and the SBOM records which document corresponds to which build. Maintaining two serialisations of the same facts is more work than maintaining one, but it is less work than a conversion pipeline that silently loses fields.
What to take away
The format choice is downstream of the toolchain. Establish what your builder emits and what your consumer ingests, check whether either side populates the minimum elements, and only then choose. Do not convert format on every build to satisfy a preference, because each conversion is an opportunity to drop the field you will need later.
Top comments (0)