Give the client whichever format their tools and reviewers already read. Both CycloneDX and SPDX are open, widely supported SBOM formats. If the client has no preference, choose one, generate it from the real build, date it, and be ready to convert. The format matters less than accuracy and freshness.
What each format is
SPDX is an open standard for sharing SBOM information, hosted by the Linux Foundation. Its own site says it is recognized as ISO/IEC 5962:2021, and that it describes provenance, licensing and security facts about software. It records facts and does not make legal interpretations of licenses.
CycloneDX is described by its project as a modular, extensible framework for supply chain information. It captures components, services, dependencies and relationships, and can cover hardware, cryptographic assets, vulnerabilities and declarations of conformance too. It is listed as ECMA-424, developed by the OWASP Foundation and Ecma International, and the project page shows version 1.7 as current.
How to decide
| Question | Lean toward |
|---|---|
| Client procurement asks for ISO recognized format | SPDX |
| Client wants one file that also carries vulnerability or service data | CycloneDX |
| Your CI platform exports one by default | Whatever it exports |
| Client has an existing scanner or inventory tool | The format that tool imports |
| No preference stated | Pick one and say which version |
GitHub's repository export, for example, produces SPDX, so a team already on GitHub can start there. Check the version, because the export tools differ in what they emit.
What the client really needs in the file
- Every direct and transitive component with a name and exact version.
- A package identifier that tools can match against advisories.
- Licenses where known.
- The relationships between components.
- A timestamp and the tool that generated it.
CISA has published a draft update to its SBOM minimum elements, with a comment period that closed in October 2025. Check CISA's page for the current status before you cite it to a client.
Mistakes agencies make
Hand-written SBOMs go stale at once. Generate the file from the lockfile or the built artifact in CI, so it matches what shipped.
Sending only a file also leaves the client unable to use it. Tell them how to read it, who updates it, and which scanner can import it.
Finally, do not treat an SBOM as proof of security. It is an inventory. It tells you what to check, not whether the result is safe.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and look at the fields listed for each package. Those are the fields an SBOM file carries.
Quick check
Do I need to supply both formats?
Usually not. Supply one unless the client says otherwise, and note that converters exist if they need the other.
How often should the SBOM be regenerated?
At every release at least. A file from launch day describes launch day.
Sources
- SPDX: About
- CycloneDX: Specification overview
- CISA: 2025 Minimum Elements for an SBOM (draft)
- GitHub Docs: Exporting an SBOM
Last reviewed: 19 October 2026.
