CycloneDX

Identity

A format created within OWASP and standardised as ECMA-424. Serialisations: JSON (recommended), XML and Protobuf.

Designed by a security community, to be produced and consumed by machines in automated chains.

Document structure

Section	Content
metadata	Timestamp, tool that produced the document, author, component described (the product itself), supplier, product licences
components	The component list: type, name, version, publisher, identifiers (purl, cpe), hashes, licences, description
dependencies	The graph: which component depends on which. This is the section that separates direct from transitive
services	External services called — useful for distributed architectures
compositions	Completeness declaration: is this inventory complete, incomplete, or of unknown completeness
vulnerabilities	Known vulnerabilities affecting the components, with source, score, state
annotations	Signed assertions about all or part of the document
formulation	How the artefact was produced: build chain, steps, environment

The compositions section is under-used and yet decisive for compliance: it lets you explicitly declare that an inventory covers only top-level dependencies, rather than implying a completeness that does not exist.

The extensions

CycloneDX is not limited to software:

Extension	Purpose
SaaSBOM	Services and interfaces of a distributed architecture
HBOM	Hardware bill of materials
ML-BOM	Machine learning models, datasets, model cards
CBOM	Cryptographic inventory — algorithms, key sizes, protocols
OBOM	Runtime configuration
VDR / VEX	Vulnerability disclosure report and exploitability assertions

CBOM deserves particular attention: it is the natural tool for preparing post-quantum migration, a topic that will meet the CRA through the state-of-the-art expectation in Annex I.

Annotated example

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-08-19T09:12:04Z",
    "tools": { "components": [ { "type": "application", "name": "syft", "version": "1.x" } ] },
    "component": {
      "type": "application",
      "bom-ref": "pkg:generic/acme-gateway@4.2.1",
      "name": "acme-gateway",
      "version": "4.2.1",
      "licenses": [ { "license": { "id": "Apache-2.0" } } ]
    }
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:maven/org.example/http-client@5.3.1",
      "name": "http-client",
      "group": "org.example",
      "version": "5.3.1",
      "purl": "pkg:maven/org.example/http-client@5.3.1",
      "licenses": [ { "license": { "id": "MIT" } } ],
      "hashes": [ { "alg": "SHA-256", "content": "9f2c…" } ]
    }
  ],
  "dependencies": [
    {
      "ref": "pkg:generic/acme-gateway@4.2.1",
      "dependsOn": [ "pkg:maven/org.example/http-client@5.3.1" ]
    }
  ],
  "compositions": [
    { "aggregate": "complete", "assemblies": [ "pkg:generic/acme-gateway@4.2.1" ] }
  ]
}

Points to note in this example:

• bom-ref is the internal key linking components and dependencies; it must be stable across builds for comparisons to be meaningful;
• purl is the identifier that makes correlation reliable — see Identifiers;
• hashes ties the inventory to the actual artefact: without a hash, nothing proves this SBOM describes the shipped binary;
• compositions.aggregate declares completeness and commits the producer.

Why it works as the pivot format

Three reasons: native support for VEX, and therefore the ability to document decisions not to fix within the same ecosystem; the richness of build metadata, useful for the traceability Annex VII expects; and the breadth of available CI/CD tooling.