CycloneDX

CycloneDX is an open exchange format for software bills of materials. It grew out of the OWASP community, has been in development since 2017, and was standardised as ECMA-424 in 2024. Practically every established bill-of-materials tool can emit it, and vulnerability platforms, package managers and supplier portals can read it.

The Cyber Resilience Act (CRA) never mentions the name. Annex I, Part II, point 1 requires vulnerabilities and components to be identified and documented, “including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products”, and deliberately names no format. Asking which format is CRA-compliant therefore leads nowhere. The obligation itself sits with the Software Bill of Materials (SBOM); the question here is whether and how CycloneDX carries it.

Article 13(24) leaves the door open: the Commission may specify the format and elements of the bill of materials by means of implementing acts, taking European or international standards and best practices into account. As long as no such specification exists, the choice is the manufacturer’s, and ECMA-424 is exactly the kind of standard a later decision could build on. No presumption of conformity follows from that: Article 27(1) ties it to harmonised standards or parts thereof, the references of which have been published in the Official Journal of the European Union.

What the format contributes to the requirement

Four properties speak directly to the wording in Annex I:

• Machine-readable against a schema. CycloneDX is written as JSON, XML or Protocol Buffers, each with a published schema. A file can therefore be checked by machine, not merely read.
• Dependencies as a graph. A dedicated section records which component pulls in which other one. Direct and transitive dependencies are told apart by position in the graph, not by a flag.
• Unique identifiers. Alongside purl, a component can carry CPE or SWID identifiers. Those are what let an entry be matched automatically against a CVE record and the relevant vulnerability databases.
• Declared completeness. A compositions section lets you state whether the recorded scope is complete, incomplete or unknown, separately for first-party and third-party content. That is where the phrase “at the very least the top-level dependencies” becomes a checkable statement.

One point is routinely missed. A valid CycloneDX file can consist of a component list alone, with no dependency information whatsoever. The legal definition in Article 3(39) expressly calls for the supply chain relationships as well. A schema-conformant file without a dependency graph satisfies the format but not the definition.

More than software components

CycloneDX describes more than libraries and frameworks. Component types distinguish applications, libraries, containers, operating systems, devices, firmware, files and data sets, and newer revisions add machine learning models and cryptographic assets. A separate services section can record the counterparts a product talks to.

Under the CRA that is more than a footnote. The legal definition of a software bill of materials covers only the components in the software elements of a product, whereas the duty in Annex I, Part II, point 1 covers the components of the product as a whole. Whatever has to be documented anyway, firmware and device parts included, can sit in the same document. Whether it should depends on the recipient: tooling built only for software components passes over the remaining entries in silence.

Vulnerability data is part of the format as well. CycloneDX can carry VEX statements on exploitability in the same document, or in a separate one that points back at the bill of materials.

Limits

The format says nothing about how the data came about. Two tools run over the same project routinely disagree, depending on whether they observe the build, read the repository or take the finished artefact apart. The CRA duty is to identify and document components; the format only records the outcome. A file that validates cleanly on top of an incomplete survey is worth nothing.

On licence data the emphasis lies elsewhere: CycloneDX adopts the SPDX licence identifiers but is built around security context, whereas SPDX comes out of licence compliance.

The file also carries no evidence of its own origin. CycloneDX provides for signatures but does not require them. Anyone passing bills of materials to authorities or customers should settle how the recipient is meant to tell that the file came from them and belongs to that exact build.

When the file leaves your hands

Nobody has to publish a software bill of materials. It becomes visible outside in three situations, and in all three what counts is that the file is readable without your tooling:

• Annex VII, point 8: on a reasoned request from a Market surveillance authority, the bill of materials must be provided where the authority needs it to check the Annex I requirements.
• Article 13(25): the Administrative cooperation group (ADCO) may decide to run a Union-wide assessment of software dependencies. Market surveillance authorities can then call on manufacturers of the affected product categories to submit their bills of materials.
• Annex II, point 9: where a manufacturer makes the bill of materials available to users, the user information has to state where it can be accessed. Handing it over is voluntary; the pointer to it then is not.

For the choice of format that yields one plain requirement: the recipient must not have to install anything to understand the file. A schema-validated JSON document meets it. An export only your own toolchain can interpret does not.