CBOM and CycloneDX: the real release history

Mental model

In the previous lesson you saw the five discovery layers; the output of the dependency layer is usually an SBOM (Software Bill of Materials). A CBOM (Cryptography Bill of Materials) is the cryptography-specific version of that idea: a document listing, in a machine-readable format, which cryptographic algorithms, protocols and keys a piece of software uses. This lesson clarifies the real release history of CycloneDX, the de facto standard for CBOMs, correcting a corpus error.

The real release history: 1.6 brought CBOM, 1.7 brought Citations

According to CycloneDX’s official GitHub release records: 1.6 was released on 9 April 2024^SOURCED and brought CBOM support (including the cryptoProperties, protocolProperties and cryptoRef fields) natively for the first time. 1.7 was released on 21 October 2025^SOURCED; a corpus error found during this research had dated 1.7 as “2026” by mistake and presented cryptoRef, protocolProperties and protobuf-based evidence as 1.7’s new features. The reality is different: cryptoRef and protocolProperties have existed since 1.6; protobuf has been supported as a serialization format since 1.3 and is nothing specific to evidence. 1.7’s real new features: a Citations mechanism (a structure that formally declares where the information in a CBOM entry came from, how it was produced and who is responsible, including confidence scores), a standard cryptographic algorithm family list, and a comprehensive elliptic curve list to support PQC readiness assessments.

This is another example of a pattern you see again and again in this course: a claim that “version X added this” must be verified directly against that project’s own release records. When a vendor tells an architect “our CBOM tool requires 1.7”, asking “for which fields, given that the basic CBOM fields have existed since 1.6” is exactly the discipline this lesson teaches.

A minimal CBOM fragment: `cryptographic-asset`

In CycloneDX a cryptographic asset is represented as a component with "type": "cryptographic-asset". The cryptoProperties field carries the asset’s type (assetType, with exactly four values in the real schema: algorithm, certificate, protocol, related-crypto-material) and type-specific details; “key” is not an assetType value here but a separate sub-field that appears under relatedCryptoMaterialProperties.type when related-crypto-material is chosen (with values such as private-key, public-key, secret-key, ciphertext, signature). For an algorithm, algorithmProperties holds fields such as the primary function (primitive: kem, signature, hash, and so on), the parameter set identifier and the NIST security category. For a protocol (protocolProperties), it holds the protocol type (such as tls or ipsec), the version, the cipher suites in use, and cryptoRefArray (often referred to simply as “cryptoRef”, but its real name in the schema is cryptoRefArray), which references the cryptographic assets (algorithms, certificates) that protocol uses; this reference mechanism is exactly what lets a bank answer “which algorithm does this TLS connection use” automatically, in an SBOM tool chain. In M13 (the migration program) you will see how this CBOM output is used as an input to a migration roadmap.

Numbers to know

CycloneDX 1.6 (9 April 2024): introduced CBOM (Cryptography Bill of Materials) natively; the cryptoProperties, protocolProperties and cryptoRef fields have existed SINCE this version

CycloneDX 1.7 (21 October 2025, the version the corpus wrongly dated '2026'): the real new features are Citations (a source and confidence attribution mechanism), a standard cryptographic algorithm family list, and a comprehensive elliptic curve list; cryptoRef/protocolProperties are NOT NEW, they have existed since 1.6

Lab: Write a minimal, valid CBOM fragment

[not run] This is a schema-writing exercise; installing a real CBOM tool is outside this course's scope

shell

# Adapt the JSON fragment below for your own component: a cryptographic-asset component, of algorithm type, for ML-KEM-768

Recorded output

{
  "type": "cryptographic-asset",
  "name": "ML-KEM-768",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "kem",
      "parameterSetIdentifier": "768",
      "nistQuantumSecurityLevel": 3
    }
  }
}

At the table

How to say this in a bank meeting.

To an executive

A CBOM (Cryptography Bill of Materials) is a cryptography-specific version of an SBOM; it records which of our components uses which algorithm in a machine-readable format, letting us automate our PQC inventory instead of tracking it by hand.

To an architect

CycloneDX 1.6 brought CBOM support natively (cryptoProperties, protocolProperties); 1.7 adds Citations on top (traceability of where, how and by whom a CBOM entry was produced). When choosing a CBOM tool, checking which CycloneDX version it targets is necessary to understand which fields it supports.

Objection

“"CycloneDX 1.7's cryptoRef is a new feature. Do we need to move to 1.7 to use it?"”

Answer

No, this is a real error found during this research: cryptoRef and protocolProperties were introduced not in 1.7 but in 1.6 (April 2024), as part of CBOM support. 1.7's real new feature is Citations; if you will only use the basic CBOM fields, 1.6 is already enough and moving to 1.7 is not required.

Sources

ESSENTIALCycloneDX specification GitHub repository (official release list)

CycloneDX / OWASP, 2025. The primary, direct source for CycloneDX's real release dates (1.6, 1.7)

releases list / 5 min

ESSENTIALCycloneDX v1.7 Delivers Advanced Cryptography, Intellectual Property, and Data Provenance Transparency

CycloneDX project, 2025. The official announcement of 1.7's real new features (Citations, the algorithm family list, the elliptic curve list)

whole text / 10 min

Project linkThe core output of Project 3 (crypto inventory and prioritization): producing a valid CycloneDX CBOM, based on this lesson's correct version information.