The software industry spent the last several years building SBOM (Software Bill of Materials) capabilities -- inventorying the components that make up software. Now a parallel challenge is emerging: inventorying the cryptographic algorithms, protocols, and implementations embedded in that software. This is the Cryptographic Bill of Materials, or CBOM.
The urgency comes from quantum computing. NIST finalized its first set of post-quantum cryptographic standards in 2024 (FIPS 203, 204, and 205). Organizations are beginning the multi-year process of migrating from RSA, ECC, and other algorithms that quantum computers will eventually break. The first step in any migration is knowing what you are migrating from. That is what a CBOM provides.
Why Cryptographic Inventory Is Hard
You might think you know what cryptography your software uses. TLS for transport. AES-256 for data at rest. SHA-256 for hashing. RSA-2048 for key exchange. But the reality in any non-trivial application is far more complex.
Transitive cryptographic dependencies. Your application might use TLS through an HTTP client library, which delegates to a TLS library, which delegates to a cryptographic primitive library. The actual cryptographic implementation is three or four layers removed from your code. You configure TLS at the application level, but the cipher suites negotiated at runtime depend on the TLS library's defaults, the server's configuration, and the negotiation protocol.
Multiple cryptographic implementations. A single application might use OpenSSL for TLS, Java's built-in java.security for certificate validation, libsodium for application-layer encryption, and bcrypt (via a native extension) for password hashing. Each implementation supports different algorithms, different key sizes, and different protocol versions.
Hardcoded algorithm choices. Developers hardcode cryptographic parameters throughout codebases: hash algorithms in integrity checks, encryption modes in data protection code, key derivation functions in authentication flows. These are scattered across configuration files, source code, and infrastructure templates.
Protocol-level cryptography. Beyond explicit cryptographic API calls, cryptography is embedded in protocols: JWT signing algorithms, SAML assertion encryption, OAuth token generation, database connection encryption, message queue TLS configuration. Each of these makes cryptographic choices that need to be inventoried.
What a CBOM Contains
A CBOM is a structured inventory of cryptographic assets in a software system. While the format is still evolving (OWASP's CycloneDX has added cryptographic properties, and IBM has published a CBOM specification), the core elements include:
Cryptographic algorithms. Every algorithm used: AES, RSA, ECDSA, SHA-256, HMAC, etc. Including the specific parameters: key size, mode of operation (CBC, GCM, CTR), curve (P-256, Ed25519), hash function variant.
Cryptographic libraries. The specific implementations: OpenSSL 3.0.12, BoringSSL, AWS-LC, java.security (JDK 17), libsodium 1.0.18. Library versions matter because they determine which algorithms are available and which are default.
Protocol configurations. TLS versions and cipher suites, SSH key exchange algorithms, IPsec configurations, certificate types and key sizes.
Key material metadata. Not the keys themselves, but metadata: key sizes, key types, creation dates, rotation schedules, key management systems used.
Certificates. Certificate authorities, signature algorithms on certificates, key sizes, validity periods, and certificate chain structures.
Cryptographic use cases. What each cryptographic element is used for: data at rest encryption, transport security, authentication, integrity verification, digital signatures, random number generation.
CBOM Generation Approaches
Static Analysis
Scan source code and configuration files for cryptographic API calls, algorithm identifiers, and protocol configurations. Tools like IBM's CBOM toolkit and CryptoGuard perform static analysis to detect cryptographic usage patterns.
Strengths: Can identify cryptographic choices in code that has not been executed. Works on any codebase without running it.
Weaknesses: High false positive rate (commented-out code, test fixtures, unused code paths). Cannot detect runtime negotiation (e.g., which TLS cipher suite is actually selected during a connection). Misses dynamically loaded cryptographic modules.
Dynamic Analysis
Monitor a running application and capture the actual cryptographic operations it performs. Intercept calls to cryptographic libraries, TLS handshakes, and key operations.
Strengths: Captures actual runtime behavior, including negotiated parameters and dynamically loaded implementations. Lower false positive rate.
Weaknesses: Only captures code paths exercised during the analysis period. Misses rarely-used functionality (error handling, fallback paths). Requires a running application with representative workload.
SBOM-Derived Analysis
Start with the SBOM and identify components that are known cryptographic libraries or that depend on cryptographic libraries. Map these to their default and configurable algorithm sets.
Strengths: Leverages existing SBOM infrastructure. Efficient for identifying the cryptographic libraries in use.
Weaknesses: Does not capture how the libraries are configured or which specific algorithms are invoked. Two applications using the same version of OpenSSL might use completely different cipher suites.
Hybrid Approach
The most effective CBOM generation combines all three: static analysis identifies cryptographic code patterns, SBOM analysis identifies cryptographic libraries and their versions, and dynamic analysis validates runtime behavior. The results are merged into a comprehensive CBOM that captures both potential and actual cryptographic usage.
Post-Quantum Migration Planning
The primary driver for CBOMs is post-quantum cryptographic migration. Without a CBOM, organizations cannot answer basic questions:
- Which systems use RSA, and at what key sizes?
- Which systems negotiate TLS cipher suites that rely on ECDH key exchange?
- Which data at rest is encrypted with algorithms vulnerable to quantum attack?
- Which digital signature schemes need to be replaced?
- What is the total scope of the migration effort?
Migration Priority Framework
Not all cryptographic assets need migration on the same timeline. Prioritize based on data sensitivity and exposure:
Immediate priority: Long-lived secrets encrypted with quantum-vulnerable algorithms. Data encrypted today might be harvested and decrypted later when quantum computers are available ("harvest now, decrypt later" attacks). If the data will still be sensitive in 10 to 15 years, migration is urgent now.
High priority: Authentication and key exchange protocols. These protect real-time communications and need to be quantum-safe before practical quantum computers exist.
Medium priority: Short-lived data encryption and integrity mechanisms. Data that is ephemeral (session tokens, temporary caches) has lower risk because it will be worthless by the time quantum decryption is feasible.
Lower priority: Hashing algorithms. While quantum computers affect hash functions (Grover's algorithm provides a quadratic speedup), the impact is less severe than for asymmetric cryptography. SHA-256 remains adequate for most purposes; SHA-384 or SHA-512 provide additional margin.
Crypto Agility
The most important outcome of CBOM-driven migration planning is not the migration itself but crypto agility -- the ability to change cryptographic algorithms without rewriting applications. If your cryptographic choices are hardcoded throughout the codebase, every future migration will be equally painful.
Design for agility:
- Abstract cryptographic operations behind well-defined interfaces
- Configure algorithms through external configuration, not source code
- Use cryptographic provider frameworks (JCA/JCE in Java, CNG in Windows) that support algorithm substitution
- Test with multiple algorithm configurations to ensure your code does not depend on specific algorithm behaviors
Regulatory Landscape
Several regulatory initiatives are driving CBOM adoption:
NSA/CISA guidance on post-quantum migration recommends cryptographic inventory as the first step. Without it, migration cannot be scoped or prioritized.
NIST SP 800-131A prescribes minimum cryptographic standards for federal systems. Demonstrating compliance requires knowing what cryptography you use.
PCI DSS 4.0 requires inventorying cryptographic protocols and algorithms used to protect cardholder data.
EU Cyber Resilience Act includes provisions for cryptographic security that will require demonstrable inventory capabilities.
How Safeguard.sh Helps
Safeguard.sh extends its SBOM capabilities to include cryptographic inventory. The platform identifies cryptographic libraries in your dependency tree, maps them to their supported algorithms and default configurations, and generates CBOM data alongside your standard SBOM. For post-quantum migration planning, Safeguard.sh flags components using quantum-vulnerable algorithms and tracks migration progress across your software portfolio. The platform provides the inventory foundation that makes structured migration planning possible, turning an overwhelming organizational challenge into a manageable, prioritized roadmap.