A Cryptographic Bill of Materials (CBOM) isn’t just a list of crypto algorithms; it’s a crucial operational security artifact that reveals the specific instances of cryptographic primitives and protocols used within a software system.
Let’s see this in action. Imagine a web service. The obvious crypto is TLS for the connection.
// Example of a TLS handshake negotiation (simplified)
ClientHello:
Cipher Suites: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, ...
ServerHello:
Cipher Suite: TLS_AES_256_GCM_SHA384
But that’s just the surface. A CBOM would also detail the specific TLS version (e.g., TLS 1.3), the exact cipher suite negotiated (e.g., TLS_AES_256_GCM_SHA384), and the specific elliptic curve used for key exchange (e.g., X25519). It goes deeper: what about the encryption of stored user data?
// Example of database encryption configuration
{
"encryption_key_id": "arn:aws:kms:us-east-1:123456789012:key/abcdef12-3456-7890-abcd-ef1234567890",
"algorithm": "AES-GCM",
"key_size_bits": 256,
"mode": "GCM"
}
A CBOM would capture the algorithm (AES-GCM), key_size_bits (256), and potentially the specific implementation library (e.g., OpenSSL 3.0.2, BoringSSL) used for this database encryption. It would also include the identifier of the specific encryption key used if managed by a KMS.
The fundamental problem a CBOM solves is cryptographic agility and inventory. In modern, complex software systems, cryptographic choices are often made by many different teams, using various libraries, and for diverse purposes (transport security, data at rest, signing, hashing, etc.). Without a CBOM, you have no clear, auditable record of what crypto is actually deployed. This makes it incredibly difficult to:
- Respond to Vulnerabilities: If a weakness is found in SHA-1, how do you know if your system is using SHA-1, and where? A CBOM provides that map.
- Enforce Policies: Are you using only approved algorithms and key lengths? A CBOM allows for automated policy checks against your deployed crypto.
- Plan Migrations: When you need to upgrade or deprecate a cryptographic primitive (e.g., move from AES-128 to AES-256), the CBOM shows you exactly what needs to change.
- Understand Risk: Knowing which cryptographic components are in use is the first step to assessing the overall cryptographic risk of a system.
Internally, a CBOM is generated by analyzing code, build artifacts, and runtime configurations. Tools can scan source code for cryptographic API calls, inspect binary dependencies for crypto libraries, and parse configuration files that specify encryption settings. The output is typically a structured data format (like JSON or YAML) that lists each cryptographic element, its purpose, its parameters (algorithm, key size, mode, version), and its origin (library, version, file path).
The most surprising aspect of a CBOM, and one most people don’t realize until they’re deep in it, is how many implicit cryptographic operations exist. It’s not just the TLS libraries or the database encryption. It’s also the digital signatures on software updates, the hashing used in integrity checks for downloaded packages, the random number generators used for session IDs or ephemeral keys, and even the cryptographic hashes used internally by data structures or serialization formats. A comprehensive CBOM often uncovers dozens, if not hundreds, of distinct cryptographic uses.
The next step after establishing a CBOM is often implementing automated tools to continuously monitor and update it as the system evolves.