SPDX and CycloneDX: choosing an SBOM format
Sytance · Updated
SPDX and CycloneDX both describe software components and their relationships. The choice depends on the information the recipient needs and the versions its tools can process. Agreeing a format therefore includes agreeing its version, encoding and required fields.
The recipient’s information needs
A firmware supplier sending an SBOM to a manufacturer may face different requirements from a team loading it into a vulnerability-management service. The recipient’s supported versions and encodings determine which files it can process. A representative file helps confirm that support.
Write down the required information, including the product identity, component identifiers, relationships, licences and any vulnerability or provenance data. If the receiver supports only part of a format, determine whether the omitted fields affect the purpose of the exchange.
Specification versions and tool support
SPDX 2.3 and SPDX 3.0.1 are separate published specifications. SPDX 3.0.1 uses a model with profiles, including a software SBOM class. A consumer that accepts SPDX 2.3 JSON should not be assumed to accept a 3.x document.
The CycloneDX specification overview lists version 1.7. Its object model includes components, services, dependency relationships and vulnerability information. A producer can support a recent specification while a downstream importer supports an earlier version.
| Exchange detail | SPDX example | CycloneDX example |
|---|---|---|
| Version | 2.3 or 3.0.1 | 1.7 |
| Document identity | Version-specific document model | Serial number and BOM version |
| Dependencies | Typed relationships | Dependency graph |
| Validation | Rules for the selected version | Schema for the selected version |
Relationships and licence fields
In SPDX 2.3, CONTAINS describes containment and DEPENDS_ON describes a dependency. A package being in an archive is different from another package needing it to build or run. Preserve the relationship type and direction when importing.
SPDX 2.3 also distinguishes a declared licence from a concluded licence. A supplier’s declaration and an analyst’s conclusion should not silently become the same field. A receiving tool needs to retain the distinction if it matters to the review.
For CycloneDX, inspect the dependency graph and component references in the chosen version. A flat component list may remain readable after conversion while losing the paths needed to investigate which product uses a component.
Checking converted information
A small test file can reveal information lost during conversion. Include a product, a direct dependency and an indirect dependency. Two versions of the same component, a licence expression and a field explicitly marked as unknown help check more than simple file acceptance.
- Validate the original against its declared specification version.
- Import it into the receiving tool and inspect the target product.
- Compare component identities, versions and relationship direction.
- Check the licence fields and the representation of unknown information.
- Export again if supported, then compare meaning rather than file formatting.
Choosing a format for delivery
If a customer requires SPDX 2.3, deliver that version with the agreed fields and keep the richer source record if conversion removes other data. If the receiving workflow already consumes CycloneDX and retains the needed graph, use the supported CycloneDX version.
If customers need both formats, maintain and test the field mappings between them. Document information that is lost or moved into extensions during conversion. A conversion must transform the data according to the target specification.
After import, check whether the recipient can still use the information as intended. For vulnerability analysis, that includes starting from a component and finding the products and releases that use it.