A CBOM — cryptographic bill of materials — is a machine-readable list of every cryptographic algorithm, key, certificate and protocol your software uses, and where. It does for cryptography what an SBOM (software bill of materials) does for dependencies, and it is the starting point for any post-quantum migration.
What goes into a CBOM?
For each cryptographic asset, typically:
- the algorithm and its parameters (for example RSA-2048, ECDSA P-256, AES-256-GCM, ML-KEM-768),
- what it is used for (key exchange, signing, encryption, hashing),
- where it was found (a file and line, a dependency, an endpoint, a certificate or a cloud service),
- whether it is vulnerable to quantum computers.
Which format do CBOMs use?
The most widely used standard is CycloneDX, which added cryptographic assets in version 1.6 (2024). Using a standard format means the same file can be read by security tools, compliance platforms and auditors without conversion.
Why do I need one?
- To plan a post-quantum migration. You need a complete list of the RSA and elliptic-curve cryptography to replace, ranked by exposure. See how to migrate.
- For auditors and regulators. Cryptographic inventories are increasingly expected by frameworks and public-sector buyers, and US federal agencies have been directed to inventory their quantum-vulnerable cryptography.
- To catch drift. Comparing today's CBOM with last month's shows new weak cryptography the moment it arrives.
How do I create a CBOM?
Building one by hand does not survive contact with a real codebase: cryptography hides in dependencies, TLS settings, certificates and cloud services, and it changes with every release. It needs to be generated by scanning. Qopanza scans your code, dependencies, TLS endpoints and cloud accounts, and exports the result as a CycloneDX 1.6 CBOM, kept up to date by continuous scanning. Start at qopanza.com.