up:: The Human & Organizational Side MOC

Cryptographic Supply-Chain Risk

Cryptographic supply-chain risk is the exposure created by the fact that most of an organization’s cryptography is inherited rather than written in-house, pulled in transitively through open-source libraries like OpenSSL, BoringSSL, and liboqs, and delivered inside the products of vendors whose own suppliers you never see. The cryptography that actually runs in production is buried several tiers deep in a dependency graph, so knowing which algorithms your estate really uses means tracing that graph rather than only reviewing the code your own team authored.

It’s the nth-party dimension of the migration: your quantum exposure depends on your library’s library and your vendor’s vendor, and the tooling that makes it legible is a software bill of materials (SBOM) linked to a cryptographic bill of materials (CBOM), backed by attestations you can actually check. This is the reach that the procurement-lever view in Vendor-Controlled Crypto Surfaces doesn’t cover, the layer below the direct vendor.

The short version:

1. Most cryptography is transitive. It arrives through open-source libraries (OpenSSL, BoringSSL, liboqs) and through third-party products, so the algorithms in production are inherited rather than authored, and a code review of your own repositories misses most of them.
2. The risk reaches the nth party, well past your direct suppliers. Your direct vendor depends on its own suppliers and libraries, so the quantum-vulnerable algorithm can sit two or three tiers below anything you signed a contract for.
3. An SBOM lists the software components; a CBOM lists the cryptography inside them. Linking the two is what turns “we ship these libraries” into “these libraries use these algorithms,” which is the mapping a migration needs.
4. Attestation is the trust layer. A supplier’s claim about its cryptography is only load-bearing if it comes as a checkable artifact (a signed SBOM/CBOM, a validation certificate) rather than a sentence in a sales deck.
5. This complements the procurement lever. Vendor-Controlled Crypto Surfaces is about pressing the vendor you buy from; supply-chain risk is about the transitive dependencies underneath that vendor, which no single contract fully reaches.

Think of the food supply chain behind a single packaged meal. The brand on the box is your direct vendor, but the box contains ingredients from suppliers the brand chose, and those ingredients came from farms and processors the suppliers chose, none of which appear on the label. If one farm three tiers back has a contamination problem, it reaches your table through a chain you can’t see from the box alone. Tracing a cryptographic algorithm through a software estate is the same problem: the vulnerable primitive can enter through a dependency of a dependency, and finding it means reading the whole ingredient list rather than only the brand name.

Why is most of your cryptography inherited rather than written?

Because building cryptography from scratch is dangerous and unnecessary, so essentially every application relies on a small number of shared, well-scrutinized libraries, and those libraries are pulled in as dependencies rather than reimplemented. A web service doesn’t write its own TLS stack; it links OpenSSL, BoringSSL, a language runtime’s crypto module, or a framework that wraps one of those. The result is that the cryptography a given system actually executes is decided by its dependency tree, often many layers deep, and frequently by transitive dependencies a developer never chose directly.

That inheritance is what makes the discovery problem hard. When you ask “does this system use quantum-vulnerable RSA or ECDH,” the honest answer usually lives in a library your team didn’t write, a version pinned in a manifest, and a build configuration that selects one provider over another. A code review of your own source will find the calls your developers made, and it will miss the cryptography a linked library performs on your behalf, which is most of it. This is the same reason discovery leans on static analysis and dependency scanning as much as on reading application code.

The migration consequence is direct: an algorithm stays invisible until you resolve the dependency graph, and a large share of your algorithms live there. That’s why the supply chain is a first-class part of the inventory rather than an afterthought.

What makes this reach the nth party, beyond your direct suppliers?

Third-party risk is the vendor you contract with; nth-party risk is everyone that vendor depends on, and cryptographic exposure routinely lives at the nth tier. Your SaaS provider builds on a cloud platform, which uses a TLS library, which depends on a math library, and a quantum-vulnerable primitive anywhere in that stack is your exposure even though you have no relationship with, and often no visibility into, the parties past the first one.

The chain has a shape worth naming explicitly, and each tier maps to a different quantum exposure:

Tier	What it is	What a self-audit sees	Where it maps
First party	Your own code and configuration	The cryptography your developers called directly	Fully visible
Third party	Vendors and open-source components you chose and can name	Only what the vendor discloses	Procurement leverage
Nth party	The suppliers, libraries, and sub-components those third parties depend on, several tiers deep	Nothing, without a bill of materials that reaches down	This note’s problem

The reason this matters for the quantum transition specifically is that the vulnerable algorithms (RSA, ECC, DH) are the default in exactly the widely-shared libraries that sit at the deep tiers, so a single un-migrated library like an old OpenSSL pinned three levels down can hold quantum-vulnerable key exchange across a whole class of products at once. NIST’s supply-chain guidance frames this as managing risk across all tiers of the supply chain rather than only the immediate supplier, which is exactly the discipline a cryptographic inventory has to inherit.

Source: NIST, “Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations,” SP 800-161 Rev. 1, May 2022 (updated November 1, 2024), SP 800-161 Rev. 1.

How does an SBOM link to a CBOM?

An SBOM (software bill of materials) enumerates the software components and dependencies in a product, and a CBOM (cryptographic bill of materials) enumerates the cryptographic assets, algorithms, protocols, certificates, and keys inside those components, so linking them turns a list of libraries into a map of which cryptography each library actually carries. The SBOM answers “what software is in here,” and the CBOM answers “what cryptography does that software use,” and the migration needs both joined.

The linkage is concrete in current tooling. The OWASP CycloneDX standard extended its SBOM format to carry cryptographic assets as a CBOM, so a single bill of materials can list a component and the algorithms, protocols, and certificates it uses, which lets the discovery of a weak or quantum-vulnerable algorithm ride on the same dependency-tracking machinery that already produces SBOMs.

Source: OWASP CycloneDX, “Cryptography Bill of Materials (CBOM),” introduced in CycloneDX v1.6, April 2024, cyclonedx.org; the CBOM capability was developed by IBM Research, OWASP Foundation announcement, owasp.org.

The practical value is that a CBOM makes the transitive cryptography queryable. Instead of manually chasing which version of which library a product pins, a linked SBOM/CBOM lets you ask “which of my components use RSA-2048 key transport” or “which still permit a classical-only TLS handshake” across the whole estate, which is the query a cryptographic inventory exists to answer and the reason the CBOM belongs at the center of a supply-chain-aware migration.

Why can’t you take a supplier’s word for its cryptography?

Because an unverified claim isn’t evidence, and cryptographic posture is exactly the kind of assertion that’s easy to state and hard to check without an artifact, so the trust layer of a supply chain has to rest on attestation rather than assurance. A supplier that says “we’re quantum-safe” or “we use strong encryption” has given you a sentence, and a sentence doesn’t tell you which algorithms, which key sizes, which protocol versions, or whether a validated module is actually in the build.

Attestation is the fix, and it’s the same evidence discipline the whole migration runs on:

1. A checkable bill of materials. A signed SBOM linked to a CBOM lets you verify the claim against a machine-readable list rather than a marketing statement.
2. A validation certificate. For the cryptography itself, a completed FIPS 140-3 CMVP module certificate is a checkable fact, where an algorithm’s presence in source is not, which is the CAVP-versus-CMVP distinction that trips people up.
3. A graded inventory entry. The same verified-versus-documented evidence grade a CBOM applies internally applies to supplier claims: a vendor datasheet is documented evidence, and a signed artifact or a validation certificate is verified evidence, and the two carry different weight in a migration plan.

The CISA/NSA/NIST quantum-readiness guidance makes vendor engagement and cryptographic inventory the core early moves precisely because a migration that trusts unverified supplier claims is building on the softest ground in the estate. Turning “they told us” into a checkable artifact is what makes the supply-chain dimension defensible.

Source: CISA, NSA, NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography,” August 21, 2023 (engage vendors and build a cryptographic inventory as core steps), cisa.gov.

Why won’t your suppliers surface this for you?

Because a supplier’s incentive is to present its product as ready, not to hand you a map of every transitive dependency and its cryptographic weaknesses, so the deep-tier exposure stays invisible unless you require it to be disclosed. That’s not usually deception, it’s the ordinary economics of a vendor managing its roadmap and its liability, and it means the burden of tracing the chain falls on the buyer who has the exposure.

The consequence for a migration is that the supply-chain view has to be built into procurement as a requirement, the same lever procurement language uses for the direct vendor, extended to demand a bill of materials that reaches the transitive components. A contract that asks a vendor “are you quantum-safe” gets a comforting yes; a contract that requires a signed SBOM/CBOM and evidence of validated modules gets a checkable answer. The difference between those two is the difference between assuming the deep tiers are fine and being able to prove which ones aren’t, and that difference is where the real cryptographic supply-chain risk is either managed or quietly inherited.

Common misconceptions

1. “We audited our code, so we know our cryptography.” A self-audit sees the cryptography your team wrote, which is the small part. Most of it is inherited transitively through libraries like OpenSSL and liboqs and through vendor products, so the dependency graph is where the real inventory lives.
2. “Vendor risk means our direct suppliers.” Cryptographic exposure routinely sits at the nth tier, in the suppliers and libraries your suppliers depend on, which no single contract reaches. Vendor-Controlled Crypto Surfaces handles the direct vendor; this is the layer beneath.
3. “An SBOM already tells us our crypto.” An SBOM lists software components, not the algorithms inside them. You need a CBOM linked to the SBOM to know which cryptography each component actually uses, which is what CycloneDX v1.6 made possible.
4. “A vendor saying ‘quantum-safe’ is enough.” An unverified claim isn’t evidence. Attestation, a signed bill of materials or a FIPS 140-3 validation certificate, is what makes a supplier’s cryptographic posture checkable rather than assumed.
5. “Open-source libraries are somebody else’s problem.” They’re your exposure the moment you depend on them. A quantum-vulnerable default in a widely-shared library is inherited by everything that links it, which is precisely why the transitive layer is a first-class part of the migration.

Questions people ask

What is cryptographic supply-chain risk? It’s the exposure that most of your cryptography is inherited transitively, through open-source libraries and through the vendors of your vendors, so the quantum-vulnerable algorithms in production can sit several tiers below anything you wrote or contracted for. Managing it means tracing the whole dependency graph rather than only auditing your own code.

How is this different from vendor-controlled surfaces? Vendor-Controlled Crypto Surfaces is about the direct vendor you buy from and the procurement leverage that moves them. Supply-chain risk is the layer underneath, the transitive open-source and nth-party dependencies that no single contract fully reaches, which is why the two are complementary rather than the same problem.

What’s the difference between an SBOM and a CBOM? An SBOM (software bill of materials) lists the software components and dependencies in a product; a CBOM (cryptographic bill of materials) lists the cryptographic algorithms, protocols, and certificates inside them. Linking the two turns a list of libraries into a map of which cryptography each one uses, which is what a migration needs.

How do I actually find transitive cryptographic dependencies? Through dependency scanning and a CBOM linked to your SBOMs, plus vendor-supplied bills of materials for the products you can’t scan. The CycloneDX v1.6 CBOM format lets the cryptographic inventory ride on the same dependency-tracking tooling that already produces SBOMs, so the transitive cryptography becomes queryable.

Can I trust a supplier’s statement that they’re quantum-safe? Only as far as you can verify it. Ask for a signed SBOM/CBOM and, for the cryptography itself, a completed FIPS 140-3 validation certificate, because those are checkable artifacts where a marketing sentence is not. This is the same evidence-grading discipline a CBOM applies internally.

Where does the standards guidance say to do this? NIST SP 800-161 Rev. 1 sets the practice of managing cybersecurity risk across all tiers of the supply chain, and the CISA/NSA/NIST quantum-readiness guidance makes vendor engagement and cryptographic inventory core early steps, so the supply-chain dimension of a quantum migration inherits an established discipline rather than inventing one.

Isn’t this just SBOM compliance? It’s more specific. SBOM compliance tracks software components for general vulnerability management, and the cryptographic supply-chain view adds the CBOM layer so you can answer quantum-migration questions (“which components use quantum-vulnerable algorithms”) that a plain SBOM can’t, which is the distinction that makes the CBOM linkage load-bearing.

---

Everything here is the map, given freely. When your team needs its transitive cryptographic dependencies traced through a linked SBOM and CBOM, its supplier claims turned into checkable attestations, and the deep-tier exposure written into procurement rather than inherited silently, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-14 · Maintained by Addie LaMarr, LaMarr Labs.