Marin Ivezic
Ask an engineering team which cryptographic algorithms their application uses and you’ll usually get a confident answer that turns out to be about half right. The answer covers the cryptography someone chose deliberately: the TLS configuration, the signing algorithm on the release pipeline, the encryption on the customer database. It misses the cryptography that arrived with a dependency, the hash function buried in a session token library, the 1024-bit key in a config file that predates the current team, and the certificate signed with an algorithm nobody has looked at since it was installed.
A Cryptographic Bill of Materials (CBOM) is the artifact that closes that gap. It is a structured, machine-readable list of every cryptographic asset in a system, together with enough detail about each one to reason about it. Not a spreadsheet someone maintains by hand. A file, generated by tooling, versioned alongside the code, and queryable.
The concept is young enough that a lot of teams have heard the acronym without seeing one. This article covers what a CBOM records, the questions it lets you answer, the questions it does not, and where it sits relative to the other inventories your organization probably already produces.
What a CBOM Records
A cryptographic asset is anything in a system that performs, enables, or depends on a cryptographic operation. That covers five categories, and a usable CBOM records all five.
Algorithms, at variant granularity. Not “AES” but AES-256-GCM. Not “RSA” but RSA-2048 with PKCS#1 v1.5 padding. The variant is where the security lives. AES-128-GCM and AES-256-CBC are both AES and they behave differently under attack, under compliance review, and under a key-management audit. A CBOM entry for an algorithm records the primitive family, the mode of operation, the padding scheme where one applies, the key length or curve, and what the algorithm is being used for: encryption, signing, key agreement, key derivation, or integrity.
Keys and key material. Type, length, encoding format, and where it lives. A 3072-bit RSA private key in PEM format on a filesystem is a materially different risk from the same key inside a hardware security module (HSM), and a CBOM that doesn’t distinguish them isn’t doing its job. Lifecycle metadata belongs here too where it is available: creation date, last rotation, scheduled expiry. Keys that were generated once in 2019 and never touched are among the most reliable findings an inventory produces.
Certificates. Subject, issuer, validity window, the public key algorithm and its parameters, and the signature algorithm on the certificate itself. That last field catches a failure mode teams miss regularly: a certificate carrying a perfectly good ECC key, signed by a certificate authority using SHA-1. The key is fine. The chain is not.
Cryptographic libraries and modules. OpenSSL, BouncyCastle, libsodium, a platform crypto provider, or a module written in-house by someone who has since left. Version matters, because vulnerabilities attach to versions. Validation status matters where you operate under a regime that requires it.
Protocols and their configuration. TLS is the common case: which versions are permitted, which cipher suites are enabled, whether session resumption is on. But the same applies to SSH configurations, IPsec transform sets, and the signing algorithm on JSON Web Tokens. Cryptography as configured is frequently not cryptography as designed, and the configuration is the part that ships.
Two more fields are worth naming because they change how much you can trust the output. Detection context records where each asset was found: the file, the line, sometimes the code snippet. Without it, remediation starts with a search. Confidence records how sure the tool is. A scanner that finds the string “AES” in a comment and a scanner that resolves a call into a cipher constructor should not report the same certainty, and a CBOM that flattens both to a bare assertion produces a cleanup queue full of ghosts.
Relationships Are the Part Teams Skip
A flat list of cryptographic assets is useful. A list that also records how those assets connect to the software is considerably more useful, and this is the piece most first attempts leave out.
Two relationships carry most of the weight. A component implements an algorithm when it contains the code that performs the operation. A component uses an algorithm when it actually calls it. OpenSSL implements dozens of algorithms. Your application probably uses four or five of them.
The distinction decides whether a vulnerability applies to you. When a flaw is announced in a specific algorithm implementation inside a widely deployed library, the question is not whether the library is present. It almost certainly is. The question is whether your code path reaches the affected function. An inventory that records only presence turns every crypto advisory into an all-hands investigation. An inventory that records usage turns most of them into a query.
The same modelling applies downward. A certificate uses a public key algorithm. A protocol configuration uses a set of cipher suites. A token format uses a signature algorithm and a hash. Once those edges are in the data, you can trace from a broken primitive to every place it surfaces, in one hop or several.
A CBOM Is Not an SBOM with Extra Columns
A Software Bill of Materials (SBOM) lists the components a piece of software is built from: packages, libraries, versions, and the dependency relationships between them. It answers “what is in this thing.” It is the foundation of most modern supply-chain security work and by now a contractual requirement in a growing number of procurement processes.
The relationship between the two artifacts is genuine. A CBOM is usually expressed as an extension of an SBOM format rather than a separate standard, and an SBOM is a reasonable starting input for building one: if the component list includes a cryptographic library, that library’s algorithms are candidates for inclusion.
But the two answer different questions, and the difference is not one of granularity. An SBOM tells you what you would need to patch. A CBOM tells you what you would need to redesign.
That distinction has teeth. Patching a vulnerable library is a version bump and a regression test. Replacing a cryptographic algorithm is a protocol change, a key-size change, a certificate reissue, an interoperability negotiation with every counterparty, and frequently a hardware constraint. The SBOM points at work measured in days. The CBOM points at work measured in quarters. Treating the second as a variation on the first is how migration programs end up with a timeline that assumes a patch cycle and a workload that behaves like a platform rewrite.
What Questions a CBOM Answers
Four questions come up repeatedly, and they are the reason to build one.
The First Question: What Weak Cryptography Is Still Running
This is the immediate return, and it usually arrives before anyone gets to post-quantum planning. Where is MD5 still in use. Which systems still permit TLS 1.0. Are there RSA keys below 2048 bits anywhere in the estate. Which certificates expire inside the next ninety days.
None of these questions is new. What is new is being able to answer them without a survey. Every organization that has run a first CBOM pass has found cryptography it didn’t know about, and the findings cluster in predictable places: legacy integrations kept alive for one customer, internal tooling that never went through security review, and vendored dependencies that pulled in their own crypto stack.
Certificate expiry deserves separate mention because it is the one finding with a hard deadline attached. An expired certificate is an outage, and outages caused by certificate expiry remain common enough to be an industry joke that no operations team finds funny.
The Second Question: What Breaks Under a Quantum Computer
A cryptographically relevant quantum computer running Shor’s algorithm would break RSA, elliptic-curve cryptography, Diffie-Hellman, and DSA. Symmetric cryptography and hash functions are affected less severely and mostly by key length.
That is a clean split, and it makes the CBOM query trivial once the data exists: list every use of RSA, ECC, DH, and DSA, and rank them by the sensitivity and lifetime of what they protect. The ranking matters more than the list. A signature verified today and irrelevant tomorrow is a different risk from a key protecting data with a twenty-year confidentiality requirement, because of harvest now, decrypt later (HNDL) exposure: an adversary who records encrypted traffic today can decrypt it whenever the capability arrives. Data with a long confidentiality life is already exposed to a machine that doesn’t exist yet.
NIST’s standardised replacements are ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation, ML-DSA (formerly CRYSTALS-Dilithium) and SLH-DSA (formerly SPHINCS+) for signatures, with FN-DSA (formerly FALCON) still in draft at the time of writing. Mapping current usage to those targets is a planning exercise. It isn’t a planning exercise you can run without knowing what your current usage is, which is the whole argument for building the inventory first.
Regulators have reached the same conclusion. The US Office of Management and Budget’s memorandum M-23-02 directed federal agencies to inventory their cryptographic systems as the first step toward post-quantum migration, and comparable inventory expectations have appeared in guidance from other national cybersecurity bodies since. The sequencing is consistent across all of them: inventory, then prioritise, then migrate.
The Third Question: How Fast Can We Change an Algorithm
Crypto-agility is the ability to change a cryptographic algorithm without redesigning the system around it. Most systems don’t have it. Algorithms get chosen once, hardcoded, and inherited by every component downstream.
A CBOM doesn’t create agility, and it is worth being precise about that. What it does is measure the cost of not having it. When the inventory shows that a single hash function appears in eleven services, three of which are third-party and one of which is a device with no update path, that is not an abstract architectural concern. That is a named list with an owner per line.
The measurement changes the conversation with engineering leadership. “We should be more crypto-agile” is a position. “Changing our signature algorithm requires coordinated changes in eleven places, two of which we don’t control” is a scoping estimate.
The Fourth Question: Are We Compliant, and Can We Show It
Cryptographic policy is easy to write and hard to verify. Most organizations have a standard that says something like: no key shorter than 2048 bits for RSA, no hash weaker than SHA-256, TLS 1.2 or higher, private keys in an HSM for anything customer-facing. Verifying that standard across a portfolio has historically meant asking people.
A CBOM turns policy verification into a query against structured data. Every rule in the standard becomes a check. Checks can run in a pipeline. Failures can block a release.
The same data serves external obligations. Where a framework requires you to demonstrate control over cryptography, a versioned inventory with a generation history is stronger evidence than a policy document and an assurance. Where a customer asks a supplier what cryptography a product uses, the inventory is the answer rather than the input to writing one.
What a CBOM Cannot Tell You
Four limits, and every team building one runs into them. Knowing them in advance changes what you plan around.
It records what is present, not what is reachable. A scanner that finds a cryptographic call in the codebase doesn’t know whether that code path executes in production. A feature flag off by default, an error handler that never fires, a compatibility shim for a client that retired last year: all of these produce inventory entries for cryptography that isn’t actually protecting anything. The consequence is that the raw finding count overstates the work, and the first pass of triage is separating live cryptography from dead code. Budget for that triage, because a team that treats every finding as remediation work will burn its first quarter on entries that could have been deleted.
Coverage depends on the discovery method, and no single method is complete. Static source analysis misses cryptography loaded at runtime, invoked through reflection, or delivered by a vendor as a binary. Binary analysis catches some of that and misses cryptography that lives in configuration. Configuration parsing catches the TLS settings and misses everything in code. Network observation shows what is actually negotiated on the wire and shows nothing about data at rest. The consequence is that a CBOM built from one source has a known shape of blind spot, and the honest posture is to name which method produced it rather than to present partial coverage as an inventory.
It doesn’t assess exploitability. A CBOM records that an algorithm is used. Whether a given weakness in that algorithm is exploitable in your specific deployment is a separate judgment, involving the threat model, the network position of an attacker, and the value of the protected data. This is the boundary where a different artifact takes over. A Vulnerability Exploitability eXchange (VEX) document is a machine-readable statement of whether a specific product is affected by a specific vulnerability, and it is where the exploitability judgment gets recorded. The CBOM supplies the facts that judgment rests on; it doesn’t make the judgment. Any tool that claims to score cryptographic risk directly from an inventory is applying a generic model to a specific system.
It describes the build, not the deployment. The cryptography in a shipped artifact and the cryptography protecting production data are two different sets, and the gap between them is where most of the surprises live.
The Two Inventories
A CBOM generated in a build pipeline describes an artifact: the code that was compiled, the libraries that were linked, the algorithms present in the shipped package. That is a real and useful thing to know.
It isn’t the same as what is running. The certificate installed on the production load balancer was not in the build. The TLS cipher suites actually permitted depend on the reverse proxy configuration, which lives in infrastructure code or, less happily, in someone’s change ticket from 2021. The keys in use were provisioned at deploy time. The HSM either exists in that environment or does not.
So there are two inventories, and they answer different questions. The build-time CBOM answers “what cryptography did we ship.” The runtime inventory answers “what cryptography is protecting our data right now.” Teams that build only the first are frequently surprised by the second, most commonly at the moment an expired certificate takes something down.
The practical recommendation is to generate both and keep them distinguishable. Build-time generation belongs in the pipeline, running on every build, with the output versioned alongside the release. Runtime inventory is harder and less standardised: it draws on configuration management data, certificate management systems, key management system exports, and where those are unavailable, on scanning the deployed environment directly. It runs on a schedule rather than on a commit.
The gap between the two is itself a finding. Where the build says one thing and the deployment says another, something in the release path is changing cryptography without going through review.
The Format Question
There is one specification carrying most of the current adoption. CycloneDX, an OWASP Foundation project originally built for software bills of materials, added a cryptographic asset component type and a set of cryptography-specific properties, and that model is what most tooling emits today. It defines the asset categories, the algorithm and certificate property sets, and the implements/uses dependency types described earlier.
The practical implication of a single dominant format is interoperability rather than lock-in. A CBOM produced by one scanner can be read by a different analysis tool, merged with an inventory from another team, and validated against a published schema. That last point is worth building into the pipeline early: schema validation catches malformed output before it reaches a system that expects to parse it, and it costs one pipeline step.
Where the standards picture is less settled is in what happens after generation. Policy encoding, cross-inventory diffing, and integration with vulnerability feeds are all being solved locally by teams writing their own scripts against the JSON. That will consolidate. Until it does, expect the format to be stable and the workflow around it to be homemade.
Making It a Habit Rather Than a Project
A CBOM generated once is a snapshot, and snapshots go stale at the rate your codebase changes. The value comes from generating them continuously and comparing them.
Three practices carry most of the benefit.
Generate on every build. If your pipeline already produces an SBOM, the CBOM step goes next to it and adds seconds rather than minutes. If it doesn’t, the CBOM is a reasonable first artifact to start with, since the argument for it is more concrete than the general supply-chain case.
Diff consecutive versions. The delta is where the signal is. A new algorithm appearing between releases means a dependency changed or a developer made a choice. A key length dropping means something regressed. A deprecated algorithm disappearing means remediation landed and can be recorded as such. Diffs also give you the audit trail: not just the current state, but evidence of the trajectory.
Encode policy as a pipeline check. Once the inventory is machine-readable, the crypto standard can be enforced rather than published. Start with a small number of unambiguous rules, because a check that fails constantly gets disabled. One banned algorithm and one minimum key length will catch more in practice than a comprehensive rule set that engineering routes around.
Two operational cautions. First, treat the CBOM as sensitive. It doesn’t contain key material, but a complete map of which algorithms protect which systems is exactly the reconnaissance an attacker would otherwise have to assemble. Apply the access controls you would apply to an architecture diagram. Second, assign an owner. An inventory that nobody reads is a file the pipeline produces, and the failure mode is subtle: the generation keeps working, the artifacts keep accumulating, and nobody notices when the findings stop being triaged.
Where to Start
Pick one application. Preferably one that matters, since the findings need to be worth acting on, but not the most complex thing in the estate, since the first pass is as much about learning the tooling as about the results.
Generate a CBOM. Read it with an engineer who knows the system, because the first output will contain entries that look alarming and are not, and entries that look routine and are not. Triage into three buckets: dead code, live and acceptable, live and needs work. That triage is the part that can’t be automated, and doing it once teaches the team what its own tooling’s false-positive profile looks like.
Then fix something. The first CBOM almost always turns up one finding that is genuinely worth remediating within the month: a certificate closer to expiry than anyone realised, a deprecated hash in an authentication path, a key that should have been rotated two years ago. Fixing it is what converts the exercise from a compliance artifact into an operational tool, and it is the evidence you will need when you propose extending the practice across the portfolio.
The post-quantum migration case is real and it is the reason CBOMs exist as a category. But the case that gets the budget approved is usually the one you find in the first pass, on a system you thought you understood.
Building cryptographic inventory capability across an organization is a program, not a tooling decision. Quantum Academy’s post-quantum readiness programs cover cryptographic discovery, inventory design, and migration planning for security architects and GRC teams, with worked examples drawn from real estates rather than reference architectures. For the migration methodology that inventory feeds into, see pqcframework.org. For deeper technical treatment of the algorithms and the threat model behind them, PostQuantum.com carries the long-form analysis.