CycloneDX is an OWASP-stewarded standard for software, hardware, and machine-learning bills of materials (SBOM). It provides a structured inventory of components, dependencies, and vulnerabilities for supply-chain transparency.
CycloneDX
CycloneDX is an OWASP-stewarded standard for producing a bill of materials (BOM) that inventories the components, dependencies, services, and known vulnerabilities that make up a piece of software, hardware, or a machine-learning model. It gives you a structured, machine-readable answer to the question “what is actually inside this thing I am running?” — expressed as JSON, XML, or Protocol Buffers so it can travel through a build pipeline and a security scanner alike.
- Full-stack BOM coverage - Software (SBOM), hardware (HBOM), machine-learning (ML-BOM), operations (OBOM), and software-as-a-service (SaaSBOM) all share one model.
- Component and dependency graph - Every component is identified with coordinates and hashes, and the dependency relationships between them are captured explicitly.
- Vulnerability and VEX exchange - Known vulnerabilities and Vulnerability Exploitability eXchange (VEX) statements ride alongside the inventory.
- OWASP stewardship - Governed as a formal OWASP flagship project and adopted by ECMA as ECMA-424, so it is an open, versioned specification rather than a vendor format.
In real API operations, CycloneDX shows up wherever the supply chain behind an API needs to be provable rather than assumed. A provider generates an SBOM at build time, attaches it to a release, and lets consumers and regulators verify which libraries — and which vulnerabilities — are shipping behind an endpoint. As the agentic turn puts more automated clients in front of APIs, a CycloneDX document becomes one of the machine-checkable trust artifacts that lets a governance layer reason about supply-chain risk instead of taking a provider’s word for it.
Industry: Security
Also in the data model catalog
This standard shows up on both sides of the house — as a standard applied in API operations here, and as a data model defining what information exists. Same standard, two lenses.
See it as a data model →Governed by these regulations
A standard is the machine-readable contract; a regulation is the law that requires it. These are the regulations that mandate or drive this standard, catalogued at regulations.apievangelist.com.
EU Cyber Resilience Act (CRA)
The CRA requires a software bill of materials covering at least the top-level dependencies; CycloneDX is one of the two formats the market actually ships.
Cyber Security Act 2024 (Cth)
Component transparency for connectable products, converging with the CRA.
Practices this standard realizes
The ways of working this standard exists to serve. A standard rarely arrives on its own — it is usually the artifact some practice needed before it could be more than an argument.
OpenChain
An alternative SBOM format serving the same conformance need, common where security is the driver.
Referenced on the API Evangelist blog
Where this standard shows up across sixteen years of my writing at apievangelist.com — how it fits into API design, governance, and the agentic turn.
The Digital API Supply Chain
2024-09-01
