CycloneDX WikiCopy Anchor Link

A full-stack Bill of Materials standard: lightweight, security-oriented, and now an Ecma international standard (ECMA-424). It describes not just software components, but services, hardware, cryptographic assets, AI models, and compliance evidence.

OverviewCopy Anchor Link

CycloneDX started in 2017 inside the OWASP community, driven by the observation that vulnerability management — not licence compliance — was the problem SBOMs actually needed to solve. That origin shows in the design: a CycloneDX document is a plain, nested, developer-readable JSON structure with first-class support for vulnerabilities, VEX, service topology, and evidence.

The project is now stewarded jointly by the OWASP Foundation and Ecma International TC54. CycloneDX 1.6 was adopted as ECMA-424 1st edition in June 2024, and CycloneDX 1.7 as ECMA-424 2nd edition on 11 December 2025 — putting it on the same procedural footing as JavaScript (ECMA-262) and JSON (ECMA-404), with ISO/IEC fast-track as the next step. For regulated buyers, that edition number is what will appear in contracts and EU Cyber Resilience Act conformity packages.

Version historyCopy Anchor Link

Good news for operations: 1.7 is fully backward compatible with 1.4 through 1.6. Older consumers simply ignore the new blocks under permissive schema parsing. The only breaking-ish changes are deprecations — for example the loose 1.6 curve string gives way to a typed algorithmFamily.curve enum, and component author gives way to authors/manufacturer.

Document anatomyCopy Anchor Link

A CycloneDX BOM is a single object with a small, predictable top-level shape. Every significant node can carry a bom-ref — a document-local identifier that other nodes point at.

Identity outward is handled by purl (package URL), cpe, and swid on each component — the same identifiers SPDX uses, which is what makes cross-format conversion feasible.

BOM flavoursCopy Anchor Link

CycloneDX deliberately uses one schema for many kinds of bill of materials:

What's new in 1.7Copy Anchor Link

1. citations — a root-level array declaring the origin of each piece of metadata: a build system, an SBOM generator, an artefact repository, or a human reviewer, with a timestamp and provenance link. It lets a consumer attribute a disagreement between two SBOMs to a specific source instead of treating the document as one undifferentiated claim.
2. Expanded CBOM — a normative algorithmFamily object (primitive type, security strength, NIST status, mode-of-operation requirements) and a closed enumeration of elliptic curves (NIST P-curves, Brainpool, Curve25519/X25519, Curve448, secp curves). The loose 1.6 curve string is deprecated.
3. Patent metadata — components can declare patents or patent families that read on them.
4. Broader formulations — the construct that described how a component was built can now describe how any referenceable object came together: services, declarations, even the BOM itself.
5. Distribution constraints — a distribution block carrying a TLP classification (CLEAR, GREEN, AMBER, AMBER+STRICT, RED) plus a free-text constraint, so downstream sharing rules travel with the document.

Also in 1.7: external components with version ranges, multiple SPDX license expressions per component, and Streebog hash support.

On TLP enforcement: the constraint is a declared policy, not a cryptographic control. It is advisory in the same way robots.txt is — a 1.7-aware repository is expected to honour it when serving the BOM, but nothing stops a careless consumer from republishing.

Vulnerabilities & VEXCopy Anchor Link

A vulnerabilities entry carries the identifier (CVE, GHSA…), affected component bom-refs, ratings (CVSS, OWASP Risk, and others), and — the important part — an analysis block with a state:

• resolved / resolved_with_pedigree — fixed, or fixed in a later version.
• exploitable — confirmed reachable and exploitable.
• in_triage — not yet assessed.
• false_positive — reported but not actually present.
• not_affected — present but not exploitable, with a justification code.

This is what turns a raw scanner dump into something an operations team can act on: the SBOM says what is there, the VEX says whether it matters.

Attestations (CDXA)Copy Anchor Link

Introduced in 1.6, CycloneDX Attestations let an organisation publish machine-readable claims, the evidence supporting them, and signatures over both — "compliance as code" instead of PDFs and spreadsheets. An attestation document references requirements, maps evidence to them, and can be signed so a consumer can verify who asserted what.

Serialization formatsCopy Anchor Link

• JSON — the primary format; schema published at cyclonedx.org/schema/bom-1.7.schema.json.
• XML — maintained in parallel with the JSON schema (1.7.2 fixed an XML schema alignment issue).
• Protobuf — supported for high-volume, streaming, and low-footprint use cases.

The project also publishes official libraries for Java, .NET, Go, Python, JavaScript, Rust, and PHP, plus build plugins for Maven and Gradle — which is why "just emit a CycloneDX BOM" is usually a one-line change in most ecosystems.

Example CycloneDX documentCopy Anchor Link

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:9f3e5b7a-2c4d-4f8e-9a1b-6c8d0e2f4a6b",
  "version": 1,
  "metadata": {
    "timestamp": "2026-09-16T09:12:00Z",
    "component": {
      "type": "application",
      "bom-ref": "acme-portal",
      "name": "acme-portal",
      "version": "1.2.0"
    },
    "tools": [{ "vendor": "anchore", "name": "syft" }],
    "authors": [{ "name": "Acme Corp" }]
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/express@4.21.1",
      "name": "express",
      "version": "4.21.1",
      "purl": "pkg:npm/express@4.21.1",
      "licenses": [{ "expression": "MIT" }]
    }
  ],
  "dependencies": [
    { "ref": "acme-portal", "dependsOn": ["pkg:npm/express@4.21.1"] }
  ],
  "citations": [
    {
      "bom-ref": "cit-syft-scan",
      "source": "tool:syft",
      "appliesTo": ["pkg:npm/express@4.21.1"]
    }
  ],
  "distribution": {
    "tlp": "AMBER",
    "constraints": "do-not-redistribute-outside-organization"
  }
}

Strengths and trade-offsCopy Anchor Link

Strengths

• Broadest tooling and library ecosystem; official plugins for most build systems.
• Security-first: vulnerabilities, VEX, services, crypto inventory, and attestations are all in the core schema.
• Approachable — a developer can read and hand-edit a BOM in minutes.
• Strong backward compatibility across 1.4 → 1.7.
• International standard status via ECMA-424, with ISO fast-track in progress.

Trade-offs

• Document-centric rather than graph-centric: cross-document linking is weaker than SPDX 3's IRI model.
• Deeply nested documents get large; the schema is broad, so implementations vary in what they actually support.
• Licensing is intentionally simpler than SPDX's ExpandedLicensing profile — it borrows SPDX IDs rather than modelling licences in depth.
• Optional-but-recommended features (compositions, pedigree, citations) are frequently left empty, which quietly reduces the value of the BOM.

Where to go nextCopy Anchor Link

Compare with SPDX → · Generators and converters → · Regulatory drivers →

Sources: cyclonedx.org, the CycloneDX specification repository release history, and ECMA-424 / Ecma TC54 announcements (retrieved September 2026).