CycloneDX CBOM

A CBOM — Cryptography Bill of Materials — is an extension of the OWASP CycloneDX SBOM standard that inventories an estate's cryptographic assets: the algorithms, protocols, certificates, keys, and related material in use, expressed in a structured, machine-readable form. Where a software bill of materials answers "what components ship in this system?", a CBOM answers the narrower and, for post-quantum planning, more urgent question: "what cryptography does this system rely on, and where?"

Why it matters

Regulators and standards now require a cryptographic inventory — OMB M-23-02 mandates one for U.S. federal agencies, and ISO 27001 A.8.24 expects controlled key and algorithm management. A CBOM turns that requirement into something automatable, diffable, and continuously maintained rather than a spreadsheet that is stale the day it is finished. Because the format is structured, tooling can flag quantum-vulnerable algorithms — RSA, ECDH, ECDSA — across a whole estate and track migration progress against a PQC migration roadmap instead of a manual audit.

What a CBOM captures, and how it is produced

CycloneDX 1.6 (2024) introduced the `cryptographic-asset` component type and its supporting properties, and that is what makes a CBOM possible. Each asset is described with enough structure for a machine to reason about it — not just "uses RSA" but the algorithm family, key size, mode, protocol context, and where it was observed. A CBOM is typically generated by scanners that inspect source, binaries, dependency manifests, and certificate stores, then consumed by governance and risk tooling that diffs successive CBOMs to show what changed:

• Cryptographic primitives — algorithm, key length, and mode (e.g. AES-256-GCM, RSA-2048, ECDH on P-256).
• Protocols and their negotiated suites — TLS versions, cipher suites, key-exchange groups.
• Certificates and keys — issuers, validity, key material references, and the assets that depend on them.
• Dependency links — which components and libraries introduce each cryptographic asset, so exposure is traceable.

How quantakrypto helps

We build a cryptographic inventory as a CBOM you can actually maintain — established during a readiness audit, regenerated in your pipeline, and wired into the rest of your toolchain alongside SARIF scan results and OpenVEX exploitability statements. From that baseline we plan and execute the move off quantum-vulnerable algorithms (migration) and conformance-test the implementations you land on (certification), with the CBOM as the ground truth that tracks progress end to end.