CBOM: The Difference Between Discovery and Intelligence

The Missing Discipline

The post-quantum conversation has a numbers problem.

Vendors love to say they have found millions of cryptographic assets. That sounds serious. It sounds comprehensive. It sounds like the sort of number a board should pay attention to.

But in most environments, that number is doing a lot of rhetorical work.

What organisations usually have are millions of cryptographic instances.

The same library. The same certificate. The same key store. The same implementation. Repeated across servers, containers, virtual machines, firmware, applications, APIs, protocols, and cloud workloads.

Counting every deployment as a separate “asset” inflates the problem and creates a false impression that every observation is a unique engineering task.

It is not.

That is the first mistake in most cryptographic discovery programmes: confusing observation volume with unique dependency count.

And that is why so many organisations end up with discovery outputs that are technically large, visually impressive, and operationally useless.

Instances Are Not Dependencies

A cryptographic instance is evidence that cryptography exists somewhere in the estate.

A cryptographic dependency is something very different.

A dependency is the underlying component or relationship that actually drives risk, ownership, migration effort, and governance action.

That distinction matters because migration does not happen at the level of raw observations. It happens at the level of dependencies, implementation chains, trust relationships, and engineering ownership.

If the same library is deployed ten thousand times, that is not ten thousand independent problems. It is one dependency with ten thousand instances.

If the same certificate chain is embedded across dozens of services, that is not dozens of separate remediation stories. It is one trust relationship expressed many times.

That is the difference between discovery and intelligence.

Why Deduplication Is Hard

Deduplication is not the same as deleting duplicate rows in a spreadsheet.

The same cryptographic implementation may appear under different library names, versions, package managers, operating systems, container images, firmware builds, or vendor products. A governance-ready CBOM has to determine whether those observations represent genuinely different implementations or multiple manifestations of the same underlying dependency.

That is a forensic problem, not a clerical one.

A tool must reconcile naming differences, version drift, build variations, metadata gaps, indirect dependencies, and inconsistent reporting across environments. Two records may look different on the surface and still point to the same cryptographic reality. Or they may look similar and actually represent different risk positions.

That is why deduplication is difficult. It is not about removing repetition. It is about proving equivalence.

And once you are doing that properly, you are no longer doing simple discovery. You are creating the intelligence needed to govern cryptographic dependencies.

Why Deduplication Matters

This is where CBOM becomes more than an inventory.

A Cryptographic Bill of Materials only becomes useful when it deduplicates repeated observations and turns them into a governance-ready view of unique cryptographic components.

That means normalising names, standardising versions, resolving aliases, correlating records that refer to the same implementation, and mapping the dependency relationships that sit underneath the noise.

In other words, deduplication is not a data-cleaning exercise.

It is a governance function.

Without it, you have a long list.

With it, you have an engineering map.

That is the missing discipline.

Most teams can discover cryptography.

Far fewer can explain which observations refer to the same underlying implementation, where that implementation is embedded, who owns it, what it depends on, and what has to change first.

That is why discovery alone does not produce migration readiness.

It produces volume.

Deduplication produces clarity.

The Economics of Noise

There is also a very practical reason boards should care.

Without deduplication, engineering effort is artificially multiplied.

Teams may investigate, test, assess, and plan the same dependency hundreds or thousands of times simply because it appears in hundreds or thousands of locations. The organisation pays for duplicated analysis, duplicated reporting, duplicated prioritisation, and duplicated governance meetings.

That is waste.

Deduplication reduces duplicated effort as much as it reduces duplicated data.

It shrinks the remediation problem into something engineers can actually sequence. It reduces false urgency. It improves budget accuracy. It stops leadership from funding repeated work against the same underlying dependency.

Every duplicated dependency you fail to recognise is another opportunity to duplicate engineering effort, inflate cost, and misrepresent risk.

That is the economic argument for CBOM done properly.

Not just fewer records.

Fewer wasted decisions.

What the Process Looks Like

A serious methodology starts with discovery.

Enumerate every cryptographic observation across the estate: libraries, algorithms, certificates, key stores, HSMs, APIs, protocols, firmware, containers, virtual machines, and cloud workloads.

Then normalise the data.

Standardise names, versions, identifiers, and metadata so the same thing is not represented five different ways by five different systems.

Then correlate.

Link observations that refer to the same underlying implementation and map where that dependency appears across applications and infrastructure.

Then deduplicate.

Collapse repeated observations into unique cryptographic dependencies so the organisation can see what truly requires attention.

Then map relationships.

Which applications consume which libraries? Which certificates depend on which CA? Which systems share the same implementation? Which trust paths break if a component changes?

Then govern.

Assign ownership. Prioritise migration. Produce engineering work packages. Build the CBOM.

That sequence is the point.

Not scan and report.

Scan, correlate, deduplicate, map, govern.

What Changes After Deduplication

Once deduplication is done properly, the conversation changes immediately.

The board stops hearing about millions of assets and starts hearing about a manageable set of unique dependencies.

Engineering stops chasing duplicates and starts working on real remediation tasks.

Budgeting becomes more accurate because the organisation is no longer funding noise.

Risk prioritisation improves because the dependency graph is visible.

And reporting becomes honest.

That is the real value of CBOM.

Not that it inventories cryptography.

That it reveals the structure beneath the inventory.

This is also why the future of cryptographic discovery is not simply about better scanning. Discovery will become increasingly commoditised. More tools will find more things. More dashboards will show more counts.

That is not the differentiator.

The differentiator will be who can produce the most accurate, deduplicated, governance-ready CBOM.

Because the hard part was never finding evidence that cryptography exists.

The hard part is understanding what is unique, what is shared, what is owned, what is exposed, and what must change.

The Real Question

So boards should stop asking: how many cryptographic assets did the tool find?

They should ask: how many unique cryptographic dependencies do we actually have?

Because you do not migrate five million assets.

You migrate the few hundred unique implementations that happen to be deployed five million times.

Discovery counts instances. Governance manages dependencies. Deduplication is the bridge between the two.

That is the difference between counting and governing.

That is the difference between noise and intelligence.

And that is the missing discipline.

#PostQuantumCryptography #PQC #CBOM #CryptographicAgility #QuantumSafe #Cybersecurity #InfoSec #CISO #RiskManagement #CryptographicInventory #CyberRisk

About SITG-Consulting

SITG-Consulting provides independent advisory services in cryptographic governance, CBOM development, Post-Quantum Cryptography (PQC), and cyber resilience.

We help organisations identify, understand and govern their cryptographic dependencies through discovery, deduplication, dependency analysis, risk assessment and migration planning.

Our approach is evidence-based, vendor-independent and focused on producing governance-ready intelligence that supports informed engineering and board-level decision-making.