| Attribute | Software Bill of Materials (SBOM) | Cryptographic Bill of Materials (CBOM) |
|---|---|---|
| Primary subject | Software components, packages, and versions | Cryptographic algorithms, key sizes, certificates, and protocols |
| Standard format | SPDX, CycloneDX (software profile) | CycloneDX 1.6 CBOM profile, now formalized as ECMA-424 |
| Main risk it surfaces | Known vulnerable dependencies (CVEs) | Deprecated or quantum-vulnerable algorithms, weak key lengths, expiring certificates |
| Typical trigger for adoption | Supply-chain compliance mandates | Post-quantum migration planning and crypto-agility mandates |
| Who consumes it | AppSec, procurement, compliance teams | Cryptography, PKI, and platform security teams |
What Is a Cryptographic Bill of Materials?
A cryptographic bill of materials, usually shortened to CBOM, is a machine-readable inventory that lists every cryptographic asset in use across an application, service, or organization. That includes the algorithms in play (RSA, ECDSA, AES, ML-KEM), the key lengths and curve parameters chosen, the certificates issued and their expiry dates, the libraries implementing the cryptography, and the protocols that negotiate it, such as TLS handshakes or SSH key exchange. Where a software bill of materials answers “what code is running,” a CBOM answers a narrower and more urgent question: “what cryptography is protecting this code, and is it still safe.”
The concept is not new in spirit. Security architects have always tried to track certificate expiry and algorithm choices in spreadsheets. What changed is scale and urgency. Modern applications pull in dozens of transitive dependencies, each with its own embedded crypto library, and the arrival of finalized NIST post-quantum standards means every one of those embedded choices is now a candidate for replacement. A spreadsheet cannot keep pace with that surface area. A CBOM, generated automatically and refreshed continuously, can.
Why CBOMs Matter Right Now
Three forces are converging to push CBOMs from a nice-to-have into a near-mandatory artifact. First, regulatory pressure is building: government guidance is moving toward requiring organizations to produce a minimum-elements CBOM in a similar way that SBOMs became a procurement requirement after prior software supply-chain mandates. Second, the finalization of FIPS 203, FIPS 204, and FIPS 205 gives every organization a concrete target to migrate toward, but you cannot migrate what you cannot see. Third, insurers and auditors assessing quantum readiness increasingly ask for an inventory as evidence of a functioning crypto-agility program, not just a policy document.
Without a CBOM, a post-quantum migration effort is guesswork dressed up as a project plan. Teams end up patching the systems they remember rather than the systems that actually carry the largest risk, and long-lived secrets protected by a forgotten legacy library get missed entirely.
CBOM vs SBOM: Where the Overlap Ends
It helps to be precise about the boundary. An SBOM tells you that a service depends on OpenSSL 3.0.2. It does not tell you which cipher suites that instance of OpenSSL is actually configured to negotiate, whether the certificate chain behind it still uses SHA-1, or whether an internal library wraps a hardcoded 1024-bit RSA key that never shows up in a dependency manifest because it is generated at build time. A CBOM captures that operational detail. In practice, mature organizations treat the two as complementary layers: the SBOM identifies components, and the CBOM drills into the cryptographic behavior of those components plus configuration-level and runtime-level crypto choices that a component list alone would never reveal.
| CBOM Field | Example Value | Why It Matters for PQC Planning |
|---|---|---|
| Algorithm family | RSA, ECDSA, AES-GCM, ML-KEM-768 | Flags classical public-key algorithms that are quantum-vulnerable |
| Key or parameter size | 2048-bit, P-256, 256-bit | Determines urgency; smaller keys fall faster to both classical and quantum attacks |
| Certificate issuer and expiry | Internal CA, expires 2027-03-01 | Natural rotation points to slot in PQC or hybrid certificates |
| Protocol context | TLS 1.2 handshake, SSH key exchange | Identifies where hybrid key exchange needs to be enabled first |
| Library and version | OpenSSL 1.1.1, BouncyCastle 1.70 | Confirms whether the underlying library even supports ML-KEM or ML-DSA yet |
| Confidentiality lifetime of protected data | 7 years, 25 years | Feeds harvest-now-decrypt-later risk scoring and remediation order |
How to Build a Cryptographic Bill of Materials: A Step-by-Step Approach
Building a usable CBOM is less about picking a tool and more about sequencing the work so the output is trustworthy enough to drive a migration budget. The following steps reflect how teams that have gotten this right actually run the project.
Step 1: Define scope and asset boundaries
Decide upfront whether you are inventorying a single application, a business unit, or the entire enterprise including third-party SaaS integrations and hardware security modules. Trying to boil the ocean on day one is the single most common reason CBOM projects stall. Start with the systems that handle the longest-lived or most sensitive data, since those carry the highest harvest-now-decrypt-later exposure.
Step 2: Pick a standard and a source format
Standardize on CycloneDX 1.6’s CBOM profile, which OWASP formalized and which has since been published as ECMA-424. Using a standard schema rather than a bespoke spreadsheet means your inventory can be consumed by downstream tooling, shared with auditors, and merged across business units without a translation layer.
Step 3: Run automated discovery across code, containers, and binaries
Static analysis tools can scan source repositories for cryptographic API calls and hardcoded parameters. Container and binary scanners catch cryptography that never appears in source, such as statically linked libraries or vendor firmware. Running both is necessary; source-only scanning misses everything shipped as a compiled dependency, and binary-only scanning misses context like which service actually invokes a given function.
Step 4: Enrich with certificate, key management, and HSM data
Pull certificate inventories from your certificate authorities and secrets managers, and reconcile them against what the code scans found. This step catches orphaned certificates issued outside the normal pipeline and confirms whether hardware security modules are already capable of PQC key generation.
Step 5: Validate, deduplicate, and assign ownership
Automated discovery produces false positives and duplicate entries across microservices sharing a base image. A human review pass, ideally by the platform security team, should merge duplicates and assign a system owner to each entry so remediation has someone accountable.
Step 6: Integrate into CI/CD and refresh continuously
A CBOM generated once is stale within a quarter. Wire the scanning step into your build pipeline so every new release regenerates or updates the relevant portion of the inventory automatically, and set a cadence for re-scanning long-lived infrastructure that does not go through a frequent release cycle.
Figure: The CBOM Generation Pipeline
Source code, container images, and binary artifacts feed into automated cryptographic discovery scanners; results merge with certificate authority and secrets-manager exports; a validation layer deduplicates and assigns ownership; the final CycloneDX-formatted CBOM is published to a central inventory that feeds both compliance reporting and PQC migration prioritization.
CBOM Generation Tools Compared
| Tool | Scans | Best Fit |
|---|---|---|
| CBOMkit (IBM, open source) | Source repositories and container images and directories via its hyperion and theia components | Teams wanting a free, self-hosted starting point with CI integration through a GitHub action |
| Sonar Cryptography Plugin | Source code cryptographic API usage inside SonarQube | Organizations already standardized on SonarQube for code quality gates |
| Commercial application security platforms | Source, dependencies, and container layers with unified dashboards | Enterprises needing vendor support, SLAs, and integration with existing AppSec suites |
| Certificate and secrets manager exports | Issued certificates, key vault entries, HSM key metadata | Filling the gaps automated code scanners cannot see |
Common mistake
Treating a CBOM as a one-time audit deliverable instead of a living artifact. Teams that generate a CBOM for a single compliance deadline and never re-run the scan end up making PQC migration decisions on data that is a year out of date, and they miss every certificate rotation and new dependency introduced since the last snapshot.
What worked
Pairing automated source and container scanning with a manual review sprint focused specifically on hardware security modules and legacy appliances. Automated tools consistently missed cryptography embedded in HSM firmware and network appliance configurations, and a two-week focused review closed most of those gaps before the inventory was considered complete.
Frequently Overlooked Items in a CBOM
- Transitive dependenciesA library three layers deep in your dependency tree can still bundle its own crypto implementation that never surfaces in a top-level manifest.
- Build-time generated keysKeys created dynamically during a build or deployment step rarely appear in static source scans.
- Protocol negotiation logsThe cipher suite a server actually negotiates in production can differ from what its configuration file suggests it should offer.
- Vendor appliance firmwareNetwork and storage appliances often embed cryptography that only a binary-level scan or vendor disclosure will reveal.
- Backup and archive encryptionLong-term backups are frequently encrypted once and forgotten, making them a prime harvest-now-decrypt-later target.
- Internal certificate authoritiesSelf-signed or internal-CA certificates issued outside a central pipeline are the most common source of orphaned inventory entries.
Using Your CBOM to Prioritize Post-Quantum Migration
An inventory is only useful once it drives a decision. Once your CBOM is populated, the next step is risk scoring: cross-reference each cryptographic asset against the confidentiality lifetime of the data it protects and the algorithm’s exposure to a future quantum adversary. Assets combining a long confidentiality lifetime, a classical public-key algorithm, and internet-facing exposure should be remediated first. This scoring exercise is exactly the input a structured migration roadmap needs, and it is worth reading alongside a dedicated post-quantum cryptography migration roadmap so the inventory work and the execution plan stay aligned. Hardware-dependent systems deserve particular attention, since the readiness of physical security modules is often the long pole in the tent; see our companion piece on hardware security module PQC readiness for what to check there. Once remediation begins, the same inventory should be extended to track hybrid deployments as they roll out, particularly for post-quantum TLS where hybrid key exchange is typically the first production change teams make. Maintaining the discipline to keep updating the CBOM as changes land is itself a crypto-agility practice, discussed in more depth in our crypto-agility guide.
Governance: Who Owns the CBOM
A CBOM that nobody owns decays quickly. The organizations that keep their inventory current typically assign a named crypto-inventory owner within the security architecture team, require every new service to register its cryptographic footprint before production launch, and hold quarterly reviews where system owners confirm or update their entries. This governance layer matters as much as the tooling; without it, the technically excellent CBOM produced in month one is functionally useless by month twelve.
Choosing Between Open Source and Commercial Tooling
Open-source options like CBOMkit are a reasonable starting point for teams that want to prove out the concept before committing budget, and they integrate cleanly into existing CI pipelines through their GitHub action. Commercial platforms tend to add value through unified dashboards that merge CBOM data with broader application security findings, vendor support contracts, and pre-built compliance reporting templates. Most enterprises land on a hybrid approach: open-source scanning at the code and container layer, feeding into whatever governance, risk, and compliance platform already anchors their security reporting.
- CBOM (Cryptographic Bill of Materials)
- A structured inventory of the cryptographic algorithms, key sizes, certificates, and libraries used across an organization’s systems.
- CycloneDX
- An OWASP-maintained bill-of-materials standard, now including a native CBOM profile, published as the ECMA-424 standard.
- Crypto-agility
- The ability of a system to swap cryptographic algorithms or key sizes with minimal redesign, typically enabled by abstraction layers and current inventory data.
- Transitive dependency
- A software component pulled in indirectly through another dependency rather than declared directly by the application.
- Hardware security module (HSM)
- A dedicated physical device that generates, stores, and manages cryptographic keys in a tamper-resistant environment.
Key Takeaways
- A CBOM inventories cryptographic algorithms, key sizes, certificates, and libraries, distinct from an SBOM’s focus on software components.
- CycloneDX 1.6, now standardized as ECMA-424, is the dominant open format for CBOM data.
- Regulatory pressure is pushing CBOMs from best practice toward a near-mandatory compliance artifact.
- Effective CBOM generation combines source code scanning, container and binary analysis, and certificate authority data.
- Hardware security modules and vendor appliance firmware are the most commonly missed inventory categories.
- A CBOM must be continuously refreshed through CI/CD integration, not treated as a one-time audit.
- The real value of a CBOM is realized when it directly feeds post-quantum migration risk scoring and prioritization.
FAQs
What is a cryptographic bill of materials in simple terms?
It is a detailed, structured list of every encryption algorithm, key length, certificate, and cryptographic library used across an organization’s applications and infrastructure, allowing security teams to see exactly where cryptography lives and how strong it is.
How is a CBOM different from an SBOM?
An SBOM lists software components and versions to track vulnerabilities like CVEs, while a CBOM drills specifically into the cryptographic algorithms, key sizes, and certificates those components use, which an SBOM alone does not capture.
What standard format should a CBOM use?
Most organizations adopt the CycloneDX 1.6 CBOM profile, an OWASP-maintained format that has since been formalized as the ECMA-424 standard, ensuring the inventory can be shared and tooled consistently.
Which tools can generate a CBOM automatically?
Open-source options include IBM’s CBOMkit, which scans source repositories and container images, and the Sonar Cryptography Plugin for SonarQube users. Several commercial application security platforms also offer CBOM generation with broader dashboard integration.
Why do regulators care about cryptographic inventories now?
With NIST’s post-quantum standards finalized, regulators want assurance that organizations actually know where vulnerable cryptography exists before quantum computers threaten it, mirroring how software supply-chain rules previously drove SBOM adoption.
What cryptographic assets are most commonly missed?
Cryptography embedded in hardware security module firmware, vendor network appliances, build-time generated keys, and orphaned certificates issued outside a central certificate authority pipeline are the categories automated scans most often miss.
How often should a CBOM be updated?
A CBOM should be regenerated continuously through CI/CD pipeline integration for actively developed systems, and re-scanned at least quarterly for legacy infrastructure that changes less frequently.
How does a CBOM support post-quantum migration planning?
Once populated, a CBOM lets teams cross-reference each cryptographic asset against the confidentiality lifetime of the data it protects, producing a risk-ranked list that tells migration teams exactly which systems to remediate first.
References
- IBM Research, “The Anatomy of Cryptography Bills of Materials: Standardization and Practice in CycloneDX”
- Checkmarx, “What Is a CBOM? Cryptographic Bill of Materials Guide”
- Cycode, “What Is a CBOM? Cryptographic Bill of Materials Explained”
- GitHub, cbomkit/cbomkit toolset repository
- GitHub, IBM/CBOM repository
- O3 Security, “CBOM: Cryptographic Bill of Materials Guide”
- Foundation for Defense of Democracies, “Cryptography Bill of Materials (CBOM): Why Every Encryption Ecosystem Needs One and Fast”
- Wikipedia, “Cryptographic bill of materials”
