If your team already produces a software bill of materials, you have solved the hard part of the cryptographic bill of materials without realizing it. You have a pipeline that inspects builds, generates a structured inventory, attaches it to releases, and feeds it into downstream tooling. A CBOM is the same discipline pointed at a different question: not which packages ship, but which cryptography they use.
The gap matters because an SBOM and a CBOM answer questions that look adjacent but almost never overlap. An SBOM tells you that a service depends on OpenSSL 3.2 and a particular JWT library. It does not tell you that the service negotiates TLS with an RSA-2048 certificate, signs tokens with ES256, pins a SHA-1 fingerprint in a legacy integration, or ships a hardcoded Diffie-Hellman group that was deprecated years ago. Those facts live below the dependency graph, in configuration, in call sites, and in certificates that no package manifest records.
This post is for teams that have an SBOM habit and want to extend it rather than start over. It covers what a CBOM entry actually captures, why the SBOM alone misses cryptography, how the CycloneDX cryptoProperties extension slots into the format you likely already emit, and how to generate the CBOM in the same CI pipeline that produces the SBOM today.
What an SBOM Sees and What It Misses
An SBOM is a dependency inventory. It records components, their versions, their suppliers, their licenses, and the relationships between them. That is enormously useful for vulnerability management: when a CVE lands against a library, the SBOM tells you every build that includes it. It is the reason supply-chain security improved as fast as it did.
But the SBOM operates at the granularity of the component, and cryptography does not live at that granularity. A single library can be configured to use strong or weak cryptography depending on how it is called. The same OpenSSL build will negotiate a post-quantum hybrid key exchange or a deprecated export cipher depending entirely on configuration the SBOM never inspects. Knowing you depend on a crypto library tells you nothing about which of its many algorithms you actually invoke, with which parameters, and against which certificates.
Consider the concrete things an SBOM cannot answer:
| Question | Answered by SBOM | Answered by CBOM |
|---|---|---|
| Which TLS library is included? | Yes | Yes (carried over) |
| Which cipher suites are negotiated at runtime? | No | Yes |
| What key sizes do our RSA and EC keys use? | No | Yes |
| Which certificates does this service present or trust? | No | Yes |
| Are we still signing anything with SHA-1 or MD5? | No | Yes |
| Which algorithms are quantum-vulnerable? | No | Yes |
| Where is a hardcoded key or static IV? | No | Partially, with code scanning |
The last column is the entire case for a CBOM. When a regulator, an auditor, or a post-quantum migration program asks “where do we use RSA-2048, and what depends on it,” the SBOM shrugs. The CBOM answers.
What a CBOM Entry Captures
A CBOM entry describes a single cryptographic asset and its properties. The useful entries are not abstract algorithm names; they are specific enough to drive a decision. A good CBOM entry captures:
- Asset type. Whether this is an algorithm, a key, a certificate, a protocol, or a related material. The CycloneDX model distinguishes these because they carry different properties.
- Algorithm and primitive. The algorithm family and the specific primitive it serves: key exchange, digital signature, encryption, hashing. ML-KEM as key encapsulation is a different fact from AES as a block cipher.
- Parameters. Key size, curve name, mode of operation, padding. RSA alone is meaningless. RSA-2048 with PKCS#1 v1.5 padding is a fact you can act on.
- Certificate detail. For certificate assets, the subject, issuer, signature algorithm, validity window, and fingerprint. This is the overlap between a CBOM and a certificate inventory, and it is deliberate.
- Protocol binding. Which protocol uses the asset and in which role. A cipher suite in a TLS 1.2 configuration is a different exposure from the same primitive in an internal signing flow.
- Quantum sensitivity. Whether the asset is vulnerable to a cryptographically relevant quantum computer. This is the field that turns a CBOM from documentation into a migration work queue.
The point of this structure is that each entry is actionable on its own. An entry reading “RSA-2048 signature, quantum-vulnerable, used in firmware signing, certificate expires 2028” is a migration ticket with a deadline attached, not a line in a report.
Audit Discovery: Expected vs. Found
Team estimated 400 certificates. Discovery found 3,200.
Compliance Gap by Framework
% of certificate estate NOT meeting framework requirements
CycloneDX cryptoProperties: The Extension You Already Support
The reason teams with an SBOM habit can adopt a CBOM cheaply is that the dominant SBOM format already defines the cryptographic extension. CycloneDX, from version 1.6 onward, includes a cryptoProperties block on components and a dedicated cryptographic-asset component type. If your pipeline emits CycloneDX today, the schema to describe cryptography is already in the documents you produce; you are simply not populating it.
The model gives each cryptographic asset a component entry whose cryptoProperties describes the asset in detail. An algorithm asset records its primitive, parameter set identifier, execution environment, and NIST quantum security level. A certificate asset records its subject, the algorithms in its chain, and its validity. A protocol asset records the version and the cipher suites in play. Related keys and ciphers link back to the algorithms that produced them.
Because these are ordinary CycloneDX components, everything your SBOM tooling already does applies. The BOM reference mechanism links a certificate to the algorithm that signed it the same way it links a package to its dependency. Your signing, your storage, your distribution to downstream consumers, and your diffing between releases all work unchanged. The CBOM is not a parallel artifact in a new format; it is additional component types inside the BOM you already ship.
This is the single most important practical fact about CBOM adoption for an SBOM team. You are not buying a new category of tool and standing up a new pipeline. You are enriching an existing document with a block the schema already reserved for exactly this purpose.
Generating a CBOM in the Same CI Pipeline
The generation step is where the two bills of materials diverge, because cryptography is discovered differently from dependencies. An SBOM generator reads manifests and lockfiles. A CBOM generator has to look in three places the SBOM generator ignores.
Source and Binary Scanning
The first source is the code itself. Cryptographic scanners parse source and compiled binaries for calls into crypto libraries, identifying which algorithms are actually invoked and with which parameters. This catches the hardcoded cipher, the explicit key size, the deprecated hash still called from one forgotten path. It is static analysis tuned for cryptographic call sites rather than general correctness, and it runs as a CI step beside your existing SBOM generation.
Configuration Analysis
The second source is configuration. TLS settings, cipher suite lists, key store declarations, and protocol version floors live in config files, not code. A CBOM step parses these to record what the service is configured to negotiate, which is frequently different from what the library could negotiate. A library that supports TLS 1.3 configured to accept TLS 1.0 is a CBOM finding the binary scan alone would miss.
Certificate and Key Discovery
The third source is the certificates and keys the artifact ships with or references. Bundled trust stores, embedded certificates, and key material referenced by path all become certificate assets in the CBOM. This is where the CBOM overlaps a certificate inventory, and the overlap is useful: the same facts feed both lifecycle management and the bill of materials.
Wiring these into CI follows the SBOM pattern exactly. Add the CBOM generation as a build stage that runs after the artifact is assembled, merge its output into the CycloneDX document your SBOM stage produces, sign the combined BOM, and attach it to the release. The CBOM inherits the SBOM’s storage, retention, and distribution because it lives in the same file. Downstream consumers that already ingest your SBOM receive the cryptographic detail automatically once you populate it.
The discipline that makes an SBOM trustworthy is that it regenerates on every build rather than being maintained by hand. The same rule is what makes a CBOM trustworthy. A cryptographic inventory assembled once in a spreadsheet is stale within a sprint. One regenerated on every build tracks the code as it changes, which is the only way it stays accurate enough to drive a migration.
Why This Matters Before a Post-Quantum Migration
The immediate payoff of a CBOM is visibility, but the strategic payoff is readiness for the migration almost every organization now faces. You cannot migrate cryptography you cannot enumerate. A post-quantum program that begins without a cryptographic inventory spends its first several months discovering what it has, by hand, under deadline pressure, and still misses the forgotten call sites.
A team that has already folded CBOM generation into its SBOM pipeline starts that program with the inventory finished and self-updating. Every quantum-vulnerable asset is already tagged. Every certificate’s signature algorithm and expiry is already recorded. The migration becomes a work queue drawn from a document the build produces, rather than an archaeology project. The teams that will migrate calmly are the ones that treated cryptography as a bill-of-materials problem before anyone forced them to.
FAQ
Q: Is a CBOM a replacement for our SBOM? No. A CBOM is an extension of it. In CycloneDX the cryptographic assets live inside the same BOM document as your software components, as additional component types. You keep producing the SBOM exactly as you do now and populate the cryptographic properties alongside it, so one signed artifact carries both.
Q: We already emit CycloneDX. What do we actually have to change?
You have to populate the cryptoProperties blocks and cryptographic-asset components that the schema already defines but your generation step leaves empty. That means adding CI stages that scan binaries and source for crypto calls, parse TLS and cipher configuration, and discover bundled certificates, then merging those findings into the BOM you already produce.
Q: Why can’t vulnerability scanning tell us this already? Vulnerability scanning works at the component level and keys off known CVEs. It flags a vulnerable library version, but it cannot tell you which algorithms you invoke, what key sizes you use, or which certificates you present, because none of that is a component version. A CBOM inspects the layer beneath the dependency graph.
Q: Does generating a CBOM slow the build down? The scanning adds a stage, but it runs in parallel with other analysis and is comparable in cost to the SBOM generation itself. The trade is a modest build-time addition for a continuously accurate cryptographic inventory, which is far cheaper than discovering the same facts manually during an audit or a migration.
Q: How does a CBOM help with post-quantum readiness specifically? Each cryptographic asset can carry a quantum-sensitivity flag and a NIST security level. Once populated, the CBOM becomes a filterable list of exactly which algorithms, keys, and certificates are quantum-vulnerable and where they are used, which is the migration work queue a post-quantum program otherwise spends months building by hand.
About QCecuring
QCecuring helps teams extend the bill-of-materials discipline they already practice into cryptography. Our platform generates a cryptographic bill of materials from the same builds that produce your SBOM, inventories every algorithm, key, and certificate with its quantum sensitivity, and feeds the result into certificate lifecycle management and post-quantum migration planning, so the inventory is finished before the deadline arrives.
Build a cryptographic bill of materials from your existing pipeline
Tags: CBOM, SBOM, CycloneDX, Cryptographic Inventory, Compliance, Post-Quantum Cryptography, Supply Chain Security, CI/CD, Certificate Discovery, Crypto-Agility, Bill of Materials, cryptoProperties