Building a Cryptographic Bill of Materials

Software supply-chain security had its inflection point when the industry standardized the SBOM — the Software Bill of Materials. Post-quantum migration has an exact analogue: the CBOM, a Cryptographic Bill of Materials. It answers the question every migration plan, audit, and regulator ultimately asks: what cryptography are you actually running, and where?

Why spreadsheets fail

Most organizations attempt their first cryptographic inventory by survey: ask every team what algorithms they use, collect the answers, produce a document. The result is out of date before it is finished, and it systematically misses the riskiest category — cryptography nobody remembers deploying. Vendored dependencies, hardcoded algorithm choices from 2013, certificates auto-renewed by forgotten automation.

Cryptography is code and configuration. Inventorying it accurately means reading code and configuration.

What automated discovery actually looks at

AutoPQC's Discovery Engine builds the CBOM from three complementary analysis passes. For Python codebases, AST-based static analysis parses source into abstract syntax trees and identifies cryptographic API usage structurally — not by grepping for the word 'rsa', but by recognizing the call patterns of cryptographic libraries, whatever the variable names.

For Java, JCA signature-pattern analysis recognizes the Java Cryptography Architecture's invocation patterns — Cipher.getInstance, KeyPairGenerator, Signature — and extracts the algorithm strings and parameters flowing through them.

For infrastructure, X.509 certificate and TLS configuration parsing reads what is actually deployed: certificate chains, key types and sizes, protocol versions, and cipher suites across the estate's endpoints.

What a useful CBOM records

A CBOM entry is more than an algorithm name. Each asset carries its location (file, service, endpoint), its cryptographic role (key establishment, digital signature, data-at-rest), its parameters (key size, curve, mode), and its exposure context. Role matters most: it determines the correct post-quantum successor — ML-KEM for key establishment, ML-DSA or FALCON for signatures, SLH-DSA where trust must last decades.

In our reference enterprise estate scan, this process surfaced 42 cryptographic assets, 36 of them quantum-vulnerable — and, more importantly, made each one addressable: mapped, prioritized, and benchmarked.

The CBOM is the start, not the deliverable

An inventory that sits in a repository is just documentation. The CBOM's value is what it feeds: risk scoring across the estate, AI-driven prioritization of what migrates first, and performance benchmarks that make the cost of each change measurable in advance. That pipeline — from visibility to defensible plan — is what turns post-quantum readiness from a slideware topic into an engineering program.