A cryptographic bill of materials (CBOM) is a machine-readable inventory of the cryptography used by a system: algorithms and their parameters, keys, certificates, protocols and the libraries that implement them. It answers questions a spreadsheet cannot answer reliably at scale: where do we still use RSA-2048? Which services depend on a library without ML-KEM support? What changed since last quarter?
CBOM versus SBOM
A software bill of materials (SBOM) lists software components and their versions. It tells you that a service uses OpenSSL 3.0, but not which algorithms that service actually calls, with which key sizes, or which certificates it presents. A CBOM adds that cryptographic layer. The two are complementary, and the CycloneDX standard supports both in the same document.
The CycloneDX 1.6 format
Since version 1.6, CycloneDX defines a component type cryptographic-asset with cryptoProperties. An asset can be an algorithm, a certificate, a protocol or related material such as a key. A minimal entry for an RSA-2048 signature looks like this:
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"components": [
{
"type": "cryptographic-asset",
"bom-ref": "crypto/algorithm/rsa-2048",
"name": "RSA-2048",
"cryptoProperties": {
"assetType": "algorithm",
"algorithmProperties": {
"primitive": "signature",
"parameterSetIdentifier": "2048",
"cryptoFunctions": ["sign", "verify"],
"classicalSecurityLevel": 112,
"nistQuantumSecurityLevel": 0
}
}
}
]
}The field nistQuantumSecurityLevel is what makes a CBOM useful for post-quantum planning: 0 means the algorithm offers no security against a quantum attacker, as for RSA and ECDSA, while ML-KEM-768 reaches level 3.
Who asks for a CBOM
- US federal government. OMB memorandum M-26-15 requires agencies to maintain an automated, continuously updated cryptographic inventory, and Executive Order 14412 asks CISA to publish minimum elements for a CBOM. Software vendors selling to federal agencies should expect to be asked for one.
- European regulations, indirectly. PCI DSS 12.3.3, DORA and NIS2 require an inventory or policies on cryptography without imposing a format. A CBOM is the most structured way to meet them.
- Agencies' migration plans. NIST, ANSSI, BSI and the UK NCSC all put discovery and inventory first.
How to produce one
A complete CBOM combines several sources:
- Network discovery of what services expose: TLS versions, cipher suites, key exchange groups and certificates. This is what our free scanner does for public endpoints.
- Static analysis of source code to find cryptographic calls, key sizes and hard-coded algorithms.
- Configuration analysis of web servers, proxies and infrastructure as code.
- Dependency analysis to know which cryptographic libraries, and which versions, each application ships.
Open-source tools exist for parts of this work, such as the CBOMkit and the Sonar cryptography plugin maintained under the Post-Quantum Cryptography Alliance. PQC Status is building a command-line scanner that runs locally, so your code never leaves your machine, and outputs a CycloneDX CBOM.
Keeping it alive
A CBOM is only useful if it stays current. Generate it in continuous integration on every release, store each version, and compare them: a new quantum-vulnerable asset in a critical service should be as visible as a new vulnerable dependency.