CBOM: expressing your cryptographic inventory in CycloneDX
A Cryptography Bill of Materials makes your inventory diffable, queryable, and CI-native. What CBOM is, how CycloneDX models cryptographic assets, and how to keep it alive.
CBOM is the format that keeps the inventory from rotting
A CBOM (Cryptography Bill of Materials) is a machine-readable inventory of cryptographic assets, standardized as an extension of CycloneDX. It models algorithms, keys, certificates, protocols, and related material as typed components with dependencies between them. Because it is structured JSON, it can be diffed on every commit, queried for "where do we still use RSA," and generated automatically in CI.
An inventory you maintain by hand is stale by the next deploy. CBOM solves that by making the inventory a build artifact. CycloneDX — the same bill-of-materials standard used for software (SBOM) dependencies — added a cryptography extension so cryptographic assets can be described in the same document format, tooling, and pipelines you already use for supply-chain security.
What CycloneDX models
CBOM represents cryptographic material as components with a cryptographic asset type. The model distinguishes several kinds:
- **Algorithm** — a specific primitive with its parameters (e.g. RSA-2048, ML-KEM-768, SHA-256), including its primitive class and, where relevant, a claimed NIST quantum-security level.
- **Certificate** — an X.509 certificate, linking to the algorithms and keys it uses.
- **Related crypto material** — keys, key pairs, tokens, secrets, and their state.
- **Protocol** — TLS, SSH, IPsec and the cipher suites or algorithms they negotiate.
Crucially, these components carry dependencies. A protocol depends on the algorithms in its cipher suite; a certificate depends on its signature algorithm and public key. That dependency graph is what lets you answer transitive questions — "which externally facing services ultimately depend on RSA key exchange?" — rather than just listing primitives in isolation.
Why the format matters for migration
- **Diffable** — a CBOM committed on each build makes the introduction of a new quantum-vulnerable dependency visible in code review, not six months later.
- **Queryable** — structured components let you filter by algorithm, quantum-vulnerability, or NIST level to generate the migration backlog directly from the data.
- **Interoperable** — because it is CycloneDX, existing SBOM tooling, registries, and vulnerability workflows can consume it without a bespoke pipeline.
- **Aggregatable** — per-service CBOMs roll up into an estate-wide view, so coverage gaps show as services with no CBOM at all.
CBOM readiness checklist
Before you call your CBOM program done, confirm: every service in scope emits a CBOM in CI; algorithm components carry parameters and quantum-vulnerability annotations; certificates and protocols link to their algorithms via dependencies; per-service documents aggregate into an estate view; and the aggregate view lists services with missing CBOMs as coverage gaps rather than silently omitting them.
Treat the CBOM as the source of truth that the roadmap reads from. When the CBOM and the roadmap share the same underlying data, the plan cannot silently drift from reality — a change that removes the last RSA dependency shows up as both a CBOM diff and a closed roadmap item.