CycloneDX
CycloneDXWhat Is CycloneDX?
CycloneDX is an open software bill of materials standard, originating in OWASP, designed around security and supply chain use cases. A CycloneDX document records the components in a piece of software, the relationships between them, and — distinctively — vulnerability and exploitability information in the same file.
Two SBOM formats are in widespread use. CycloneDX was built from a security starting point. SPDX began as a licence-compliance format and acquired security capability later. Both are mature and both are machine-readable.
Knowing which your consumers expect is a commercial matter rather than a technical preference. An enterprise buyer whose ingestion pipeline accepts only one format will treat the other as equivalent to no SBOM at all.
How CycloneDX Differs From SPDX in Practice
The formats overlap substantially, and most modern tooling can emit either. The differences that affect a real decision:
- Vulnerability and VEX data are native to CycloneDX, carried in the same document as the component inventory rather than alongside it.
- CycloneDX extends beyond software to hardware, services and machine learning models, which matters as AI components enter supply chains.
- SPDX carries deeper licence provenance and is an ISO standard (ISO/IEC 5962:2021), which some legal teams require by name.
- Conversion between them is lossy at the edges, so generating each at build time beats translating one into the other afterwards.
Neither is better in the abstract. Produce whichever your consumers ask for, and be prepared to produce both.
What Makes an SBOM Useful Rather Than Just Present
Format is the question teams ask first and it is rarely the one that matters. Depth is.
An SBOM listing only direct dependencies tells a consumer very little, because the components that cause incidents are usually several levels down. Worse, a shallow SBOM presented as complete creates a fresh disagreement about what was omitted and why.
What separates a useful SBOM from a box-ticking one:
- Transitive dependencies included, not just the top level.
- Generated at build time from the actual build, rather than reconstructed afterwards by scanning the artifact.
- Signed or attested, so it is evidence rather than an assertion.
- Accompanied by VEX, so findings against it can be answered in the same machine-readable channel.
How to Use CycloneDX in Production Environments
Producing the document is the easy part. Making it operationally useful takes a little more:
- Generate at build, not after. A build-time SBOM knows what went in; a post-hoc scan infers it and will miss anything installed outside a package manager.
- Attach it to the artifact rather than filing it somewhere, so it travels to whoever scans the image next.
- Include licence data if legal clearing is part of your sales process, since that request usually arrives late and under time pressure.
- Ask your consumers which format and which version they ingest, before a deal depends on the answer.
- Keep historical SBOMs for artifacts still running in production, because incident response needs the SBOM for the version deployed, not the current one.
How Hardened Container Images Ship CycloneDX
For an image provider, the SBOM is the mechanism by which a customer verifies the image rather than trusting a claim about it.
Echo states that its images are delivered with a software bill of materials, provenance data and VEX, built at SLSA L3 (echo.ai/product). The useful question to put to any provider is about depth and format: whether transitive dependencies are included, which format is emitted, and whether licence texts come with it.
Depth is also what makes the SBOM usable in the scanner-disagreement case, where a consumer needs to verify contents independently rather than infer them from a tag. The format comparison is covered in more detail in 10 best SBOM generation tools.
FAQs
Should we produce CycloneDX or SPDX?
Whichever your consumers ingest, and increasingly both. CycloneDX suits security workflows because vulnerability and VEX data are native to the format. SPDX is an ISO standard with deeper licence provenance, which some legal teams require explicitly. Generating both at build time is cheaper than converting later, since conversion loses detail at the edges.
Is a partial SBOM better than none?
Usually not. A document listing only direct dependencies invites a second argument about what was omitted and why, and it undermines confidence in the parts you did include. If you cannot yet produce transitive dependencies, say so explicitly rather than shipping something incomplete that presents itself as complete.
Can an SBOM be generated after the build?
It can, by scanning the finished artifact, but it will be less reliable. A post-hoc scan infers contents from package manager metadata and file fingerprints, so anything installed outside a package manager or vendored into another component may be missed. A build-time SBOM records what actually went in.
Does CycloneDX replace a vulnerability scanner?
No. An SBOM is an inventory; a scanner compares an inventory against vulnerability databases. CycloneDX can carry vulnerability assertions, but those are statements made by the producer rather than an independent assessment. The two are complementary: the SBOM makes scanning accurate, and scanning makes the SBOM actionable.
How long should we retain SBOMs?
At least as long as the corresponding artifact runs anywhere in production, and ideally through your stated support period. Incident response needs the SBOM for the version actually deployed, which may be considerably older than your current build. Treat SBOM retention as part of your release archive rather than as build output.
