No application implements its own cryptography, or at least no well-run one does. The algorithms, the protocol handshakes, the key operations, all of it is implemented by a cryptographic library, and that library arrived in the application not because someone chose it directly but because it was pulled in as a dependency, often several layers down a chain the developers never examined. A web framework depends on an HTTP library, which depends on a TLS library, which depends on a cryptographic module, and the team that built the application may have no idea which crypto implementation is ultimately doing the work or which version of it. This is the crypto supply chain, and it is invisible to any inventory that looks only at what the application declares about itself.
The implication is that a cryptographic inventory cannot stop at the algorithms and certificates it can observe in use. It has to reach down to the implementations, the libraries that actually perform the cryptography, because that is where vulnerabilities live, where quantum-readiness will or will not be delivered, and where the ability to change an algorithm ultimately rests. A weakness in a widely used crypto library is not one application’s problem; it is every application’s problem that depends on it, transitively, whether or not those applications know the dependency exists. Discovering crypto libraries, correlating them to the crypto assets they implement, and tracing how they arrive is the capability that connects a Cryptographic Bill of Materials to the broader software supply chain.
This post explains how crypto library discovery works, how it relates to the Software Bill of Materials that supply-chain programs already produce, and why the two bills are stronger together than either is alone.
Audit Discovery: Expected vs. Found
Team estimated 400 certificates. Discovery found 3,200.
Compliance Gap by Framework
% of certificate estate NOT meeting framework requirements
Cryptography Is Implemented by Libraries You Did Not Choose Directly
The cryptographic landscape rests on a relatively small set of implementations that an enormous amount of software depends on. Knowing which of them is present, and where, is foundational, because the properties of the implementation determine the properties of every cryptographic operation built on it.
| Cryptographic Library | Typical Context |
|---|---|
| OpenSSL | Pervasive across servers, languages, and operating systems |
| BoringSSL | Google-maintained fork, common in Chromium-derived and Google software |
| wolfSSL | Embedded and resource-constrained environments |
| mbedTLS | Embedded and IoT devices |
| Bouncy Castle | Java and .NET ecosystems |
| Java JCA and JCE | The cryptographic framework built into the Java platform |
| Microsoft CNG and CAPI | The Windows cryptographic providers |
| NSS | Mozilla’s library, common in Firefox-derived and Red Hat software |
| libsodium | Modern applications favoring a high-level, hard-to-misuse API |
The point of enumerating these is not completeness for its own sake. It is that each implementation has its own vulnerability history, its own release cadence, its own quantum-readiness trajectory, and its own upgrade path, and an application’s cryptographic posture is inherited from whichever of these is actually linked into it. Two applications that both “use TLS” can have entirely different risk profiles because one links a current, actively maintained library and the other links an old version of a library that stopped receiving fixes years ago. The algorithm names look identical. The implementations do not, and the implementation is what gets exploited.
Discovering Crypto Libraries Across the Estate
Crypto libraries do not sit in one place or arrive by one route, so discovery has to reach them wherever they are: compiled into binaries, packaged inside container images, and declared in dependency manifests. Each surface reveals the supply chain from a different angle, and a complete picture requires all three.
Binaries carry statically or dynamically linked crypto libraries that may not appear in any manifest, because the manifest describes source dependencies while the binary reflects what was actually linked at build time. Container images bundle libraries at every layer, including base-image libraries that the application team never selected and may not know are present. Dependency manifests declare what the build intends to pull in, including the transitive dependencies that bring crypto libraries along without any direct reference. Reading only one of these surfaces produces a partial and misleading inventory: a manifest-only view misses what was actually linked, a binary-only view misses the declared intent and version provenance, and a container view without manifest and binary analysis sees layers without understanding what pulled each library in.
The discovered library is then tied to a version and, through that, to its known vulnerability and maintenance status. A crypto library is not a static fact; it is a specific version with a specific history, and the version is what determines whether a known weakness applies. Discovering that an application contains a given library is the start; discovering which version, and whether that version carries unresolved cryptographic weaknesses, is the finding.
Correlating Crypto Assets to Their Implementations
Library discovery becomes far more valuable when it is joined to the rest of the cryptographic inventory. Every crypto asset the platform observes, a TLS configuration, a signing operation, a key usage, is performed by some implementation, and correlating the asset to the library implementing it answers a question that neither view can answer alone: not just what cryptography is in use, but what is performing it and whether that performer is sound.
This correlation changes the nature of a vulnerability. When a weakness is disclosed in a crypto library, the question every organization scrambles to answer is “where does this affect us, and how badly.” An inventory that has correlated crypto assets to their implementing libraries can answer immediately: these services perform cryptography through the affected library, these are internet-facing, these handle the most sensitive operations. Without that correlation, the organization is left grepping dependency files and hoping the manifests are complete, which they rarely are. The correlation turns a frantic, days-long hunt into a query.
It also reframes remediation. The ability to change an algorithm or retire a weak protocol often depends entirely on the library, because the library determines what algorithms are available and how they are selected. An application cannot adopt a new signature scheme its linked library does not implement, and cannot drop a weak one the library defaults to without a library-level change. Correlating assets to libraries is therefore what makes crypto-agility assessment honest: it grounds “can we change this” in “does the implementation that performs it support the change.”
Tracing Transitive Crypto Dependencies
The hardest and most important part of supply-chain crypto discovery is tracing the transitive chain: application depends on framework, framework depends on a protocol library, protocol library depends on a crypto module. The crypto module at the bottom is the one doing the actual work, and it is usually the one the application team is least aware of, because every layer between them obscured it.
Tracing the chain matters for two reasons. First, responsibility and blast radius follow the chain: a weakness in the crypto module at the bottom propagates up through every layer to every application at the top, and understanding the chain is what lets you enumerate the affected applications rather than discovering them one incident at a time. Second, the chain reveals where a fix has to happen. If the weak algorithm is defaulted deep in a transitive crypto module, no amount of configuration at the application layer fixes it; the fix has to come from updating the module or the intervening layer that selects its behavior. A flat list of dependencies cannot show this. A traced chain can, and tracing it is the difference between knowing you have a problem and knowing where to apply the fix.
Where CBOM and SBOM Meet
The Software Bill of Materials and the Cryptographic Bill of Materials are related but not the same, and the relationship is worth stating precisely, because confusing them produces inventories that each think the other’s job is being done.
An SBOM enumerates software components and their versions: the libraries, frameworks, and modules that make up an application. A CBOM enumerates cryptographic assets and their properties: the algorithms, keys, certificates, protocol configurations, and the implementations behind them. The overlap is the crypto library, which is a software component (so it belongs in the SBOM) that implements cryptography (so its cryptographic properties belong in the CBOM). The SBOM says “this application contains version X of this library.” The CBOM says “this library implements these algorithms with these properties, performs cryptography for these services, and carries this quantum and vulnerability exposure.” One describes presence; the other describes cryptographic meaning.
| Aspect | SBOM | CBOM |
|---|---|---|
| Primary unit | Software components and versions | Cryptographic assets and their properties |
| Crypto library | Listed as a component | Characterized by what it implements and its crypto risk |
| Core question | What is in this software | What cryptography is present and how strong it is |
| Shared ground | The crypto library appears in both, from different angles | The crypto library appears in both, from different angles |
This is why the two bills are stronger together. An SBOM that knows a crypto library is present but nothing about its cryptographic properties cannot assess quantum or algorithm risk. A CBOM that knows cryptographic assets but cannot tie them to the versioned components implementing them cannot connect a library vulnerability to the assets it endangers. Expressing both in a common, interchangeable format, with the industry converging on CycloneDX as the representation that carries software and cryptographic components together, is what lets a supply-chain program and a cryptographic program draw on the same underlying data rather than maintaining two disconnected inventories. A platform that can ingest an existing SBOM, enrich it with cryptographic characterization, and emit a combined bill is doing the integration that makes both useful.
The supply-chain story continues to evolve in how exploitability is communicated. Attaching structured exploitability context to components, so that a known library weakness can be marked as not-affecting a particular deployment because the vulnerable code path is never reached, is where supply-chain tooling is heading. That kind of exploitability annotation is emerging across the ecosystem rather than a settled, present-tense capability, and the honest framing is that the combined software-and-crypto bill is the foundation on which that richer exploitability context will be built.
FAQ
Q: Why does a crypto inventory need to discover libraries, not just algorithms? Because the library is the implementation, and the implementation determines the real risk. Two applications that both “use TLS” can have entirely different exposure because one links a current library and the other links an old, unmaintained version. Vulnerabilities, quantum-readiness, and the ability to change an algorithm all live in the library, so an inventory that stops at algorithm names misses where the actual risk and the actual fixes are.
Q: Where are crypto libraries actually discovered? Across three surfaces that each reveal a different angle: binaries show what was statically or dynamically linked at build time, container images show libraries bundled at every layer including the base image, and dependency manifests show declared and transitive dependencies. Each alone is partial, so a complete picture combines all three and ties every discovered library to its specific version and maintenance status.
Q: What does correlating crypto assets to libraries make possible? It turns a vulnerability scramble into a query. When a library weakness is disclosed, a correlated inventory can immediately name the services that perform cryptography through that library, which are exposed, and which are most sensitive, instead of grepping manifests and hoping they are complete. It also grounds crypto-agility assessment, because whether you can change an algorithm depends on whether the implementing library supports the change.
Q: How is a CBOM different from an SBOM? An SBOM enumerates software components and versions; a CBOM enumerates cryptographic assets and their properties. They overlap at the crypto library, which is a software component that implements cryptography. The SBOM records that the library is present; the CBOM records what it implements, what it performs cryptography for, and its quantum and vulnerability exposure. Expressed in a common format like CycloneDX, the two bills reinforce each other.
Q: Can existing SBOM data be reused for a CBOM? Yes. A platform can ingest an existing SBOM, enrich its components with cryptographic characterization, and emit a combined bill that carries both software and cryptographic components. That reuse is the practical meaning of CBOM meeting SBOM: one underlying dataset serving both the supply-chain program and the cryptographic program rather than two disconnected inventories maintained in parallel.
About QCecuring
QCecuring discovers cryptographic libraries across binaries, container images, and dependency manifests, correlates each cryptographic asset to the versioned library implementing it, and traces transitive crypto dependencies down to the module doing the work. It ingests, generates, and enriches software and cryptographic bills in CycloneDX, so a library weakness becomes a query against affected services rather than a frantic manifest hunt.
See which services a crypto library weakness would actually reach
Tags: CBOM, Supply Chain Security, SBOM, CycloneDX, OpenSSL, Crypto Libraries, Transitive Dependencies, Container Security, Bouncy Castle, Dependency Analysis, Vulnerability Management, Enterprise Security