Press enter or click to view image in full size

Cbomkit

Pqc Migration

Cryptography

Cryptographic Discovery

Nist

You Can’t Migrate What You Can’t See: Building the Evidence Engine for Cryptographic Discovery

Aamir Hameed

8 min read

·

Aug 28, 2026

--

Listen

Share

One of the hardest problems in the transition to post-quantum cryptography is not implementing a new algorithm.

It is answering a much more basic question:

Where is cryptography actually being used?

An organization may have thousands of applications, servers, devices, firmware images, certificates, repositories, APIs and third-party dependencies. Somewhere inside that environment may be RSA, ECDSA, Ed25519, classical key exchange, hashing algorithms, post-quantum algorithms and proprietary cryptographic implementations.

Before an organization can migrate any of it, it first needs to know what exists, where it exists, how it is being used, and how certain we are that the discovery is correct.

This is the problem we are beginning to address at Sirraya Labs with Sirraya CBOM.

And we are deliberately approaching it differently.

We are not starting with a dashboard.

We are starting with an evidence engine.

What is a Cryptographic Inventory?

A conventional asset inventory answers:

What systems and assets do we have?

A cryptographic inventory asks a different question:

What cryptographic mechanisms are associated with those assets?

For example, an organization might have:

Payment API
 ├── ECDSA P-256 certificate
 ├── RSA-2048 dependency
 └── SHA-256

Firmware
 ├── Ed25519 signature verification
 └── SHA-256Device Gateway
 ├── ECDSA P-256
 └── X25519Build Pipeline
 └── ML-DSA signing

This information becomes the foundation for understanding cryptographic exposure and eventually planning migration.

But there is a fundamental problem.

How do you know these findings are actually correct?

That question is at the heart of our architecture.

Discovery is not the same as evidence

Imagine a scanner finds this in a project’s Cargo.toml:

rsa = "..."

Does that prove the application uses RSA?

No.

The dependency may be present but never imported.

Now imagine a binary scanner finds:

RSA_verify

That is stronger evidence.

Now imagine a runtime sensor observes an actual RSA verification operation.

That is stronger still.

We therefore don’t want our system to treat every discovery as equivalent.

Instead, we want to preserve what was observed, where it was observed, how it was observed, and which independent evidence sources agree with it.

That is why sirraya-cbom is deliberately not a scanner.

The architecture begins with evidence

The architecture separates discovery mechanisms from the system that reasons about their output.

Future discovery components can specialize in different evidence sources:

Source Code
     │
Binary
     │
Certificates
     │
TLS
     │
Firmware
     │
Dependencies
     │
Runtime
     │
     ▼
┌─────────────────────┐
│   Sirraya CBOM      │
│   Evidence Engine   │
└─────────────────────┘
          │
          ▼
    Normalization
          │
          ▼
      Correlation
          │
          ▼
   Confidence Fusion
          │
          ▼
   Cryptographic Finding
          │
          ▼
      CBOM Output

This separation is intentional.

The scanners report what they saw.

The evidence engine determines how those observations should be represented, correlated and evaluated.

Seven discovery surfaces, one evidence model

Cryptography can hide in many places.

A source-code scanner may find a cryptographic API.

A dependency scanner may find a cryptographic library.

A binary scanner may identify symbols or implementation fingerprints.

A certificate scanner may discover a public-key algorithm.

A TLS scanner may observe what is actually negotiated over a live connection.

A firmware scanner may uncover cryptographic components buried inside an image.

A runtime scanner may observe cryptographic operations that static analysis could not establish conclusively.

Each of these provides a different window into the same underlying system.

The challenge is preventing those observations from becoming seven disconnected inventories.

Sirraya CBOM is designed to bring them together.

Canonical algorithm identity

One of the first problems we are solving is deceptively simple:

different systems use different names for the same algorithm.

You might encounter:

RSA
RSA2048
rsaEncryption
EVP_PKEY_RSA

If every scanner treats those strings as independent identifiers, an enterprise inventory quickly becomes polluted with duplicates.

Sirraya CBOM introduces a canonical algorithm identity layer.

Conceptually:

RSA
RSA2048
rsaEncryption
EVP_PKEY_RSA
       │
       ▼
Canonical Algorithm
       │
       ▼
RSA / 2048-bit

The same principle applies to other cryptographic nomenclature.

For example:

P-256
prime256v1
secp256r1
NIST P-256

should not become four different cryptographic assets simply because four tools use different terminology.

Our canonical algorithm model is also connected directly to the algorithm vocabulary exposed by Sirraya Crypto, allowing discovery and cryptographic implementation layers to share a consistent identity model.

Evidence is a first-class object

We don’t want evidence to be a text field saying:

“Found RSA somewhere.”

Evidence needs structure.

A finding should be able to answer:

What was found?

Where was it found?

Which scanner found it?

What exactly matched?

When was it observed?

What type of evidence is it?

Conceptually:

Crypto Evidence

Asset:
    payment-apiAlgorithm:
    RSA-2048Observation:
    RSA verification symbolSource:
    Binary analysisLocation:
    application ELFMatch:
    RSA_verifyConfidence contribution:
    Binary evidence

This means the final inventory remains traceable back to its underlying observations.

That becomes extremely important when the inventory is used for security decisions.

From individual observations to a CryptoFinding

Multiple observations should not automatically create multiple findings.

Suppose we have:

Dependency scanner
    ↓
RSA library detected

Binary scanner
    ↓
RSA verification symbol detectedRuntime scanner
    ↓
RSA verification observed

The system should understand that these observations may describe the same underlying cryptographic usage.

They are evidence contributing to one finding:

CryptoFinding

RSA-2048
Usage: Signature VerificationEvidence:
    ✓ Dependency
    ✓ Binary
    ✓ Runtime

This is where the evidence engine becomes more than a data store.

It becomes the layer that correlates cryptographic observations into an explainable finding.

Confidence should be explainable

We are deliberately avoiding the idea of a mysterious numerical score that says:

Confidence: 87%

That number is not very useful if nobody can explain where it came from.

Instead, confidence should be based on understandable evidence.

For example:

LOW

✓ Dependency declarationBut:
✗ Not confirmed in binary
✗ Not observed at runtime

versus:

HIGH

✓ Dependency evidence
✓ Binary evidence
✓ Runtime evidence

The principle is simple:

Independent evidence agreeing with one another should provide stronger confidence than a single weak observation.

This is why the architecture calls it confidence fusion.

And importantly, the rules are intended to be explicit and auditable rather than hidden inside a black-box scoring system.

A dependency is not proof of usage

This distinction deserves special emphasis.

Consider:

Cargo.toml
    rsa = "0.9"

A conventional dependency inventory might immediately report:

RSA present.

But the real question is:

Is RSA actually used?

Perhaps the dependency exists because of an unused feature.

Perhaps another dependency brings it transitively.

Perhaps it is compiled out of the production build.

Perhaps the production binary uses a completely different implementation.

This is why our model treats different evidence sources differently.

A dependency declaration is useful evidence.

It is simply not equivalent to observed runtime behavior.

That difference becomes critical when an organization is making migration decisions.

Coverage matters as much as findings

There is another problem with cryptographic discovery:

not finding something does not necessarily mean it isn’t there.

Suppose a scanner says:

No RSA found.

That statement is meaningless without knowing what was actually scanned.

Did we inspect:

• 10 files?
• 10,000 files?
• binaries?
• dependencies?
• certificates?
• firmware?
• runtime traffic?

Our architecture therefore explicitly leaves room for negative and coverage evidence.

Eventually, the system should be able to say something closer to:

Scan coverage

Files scanned:       4,218
Binaries analyzed:      37
Certificates:           112
Firmware images:          8
TLS endpoints:           24Scanner versions:
    source-v3
    binary-v2
    cert-v2
    tls-v1Coverage:
    93.7%Unknown / inaccessible:
    12 assets

Now:

“No RSA detected”

has context.

This is a much more honest and useful security statement.

Claimed versus observed cryptography

Another capability we are designing toward is reconciliation between what a system claims to use and what we actually observe.

For example:

Configuration says:
    ML-DSA

Binary says:
    RSARuntime says:
    RSA

That is not merely an inventory record.

That is a security discrepancy.

Or the reverse:

Configuration:
    RSA

Runtime:
    ML-DSA

Again, something interesting has happened.

This distinction between claimed cryptographic state and observed cryptographic state becomes increasingly important as organizations migrate systems.

A migration plan should not be based only on what configuration files say.

It should be based on evidence.

Why CBOM?

The output of all this work needs to remain interoperable with the broader ecosystem.

That is where CBOM — Cryptography Bill of Materials — comes in.

An SBOM describes the software components inside a system.

A CBOM describes the cryptographic components associated with that system.

Sirraya CBOM is designed to export the resulting inventory as a CycloneDX 1.6 cryptographic-asset document.

But we don’t want interoperability to mean throwing away the information that makes our findings useful.

Where the standard does not provide a native representation for our richer evidence and confidence information, we preserve that information through a Sirraya-specific properties namespace.

So the architecture becomes:

Discovery
    ↓
Evidence
    ↓
Canonicalization
    ↓
Correlation
    ↓
Confidence
    ↓
Inventory
    ↓
CycloneDX CBOM

Standards compatibility on the outside.

Richer evidence internally.

Why we believe this approach is different

There are already tools that can generate CBOMs and identify cryptographic components.

We are not claiming that cryptographic discovery itself is a new idea.

Our focus is on a different layer of the problem.

We want the inventory to retain the reasoning behind the finding.

Instead of:

RSA-2048

we want to be able to represent:

RSA-2048

Found by:
    dependency analysis
    binary analysis
    runtime observationEvidence:
    RSA library
    RSA_verify symbol
    observed verificationConfidence:
    HIGHAsset:
    firmware-loaderUsage:
    signature verification

And ideally, someone should be able to move from that finding back to the evidence that produced it.

That is the foundation of an evidence-driven cryptographic inventory.

Why we are building this underneath Sirraya Crypto

This work also connects directly to our broader cryptographic engineering at Sirraya Labs.

Sirraya Crypto provides the cryptographic implementation foundation.

Sirraya CBOM provides a structured way to understand cryptographic usage and evidence.

The relationship is important because discovery and migration need a common cryptographic vocabulary.

If the inventory identifies:

RSA-2048
ECDSA P-256
Ed25519
ML-DSA
SLH-DSA
LMS
XMSS

the system should not merely know their names.

It should understand them as canonical cryptographic identities and, where appropriate, understand their relationship to the cryptographic capabilities available in the underlying Sirraya ecosystem.

That gives us a path from:

discovering cryptography

to:

understanding cryptography

without making those two problems independent systems.

This is the foundation, not the dashboard

The temptation with security products is to start with the visual layer.

A beautiful dashboard can show:

RSA: 42%
ECDSA: 31%
Ed25519: 18%
PQC: 9%

But a percentage is only as trustworthy as the discovery process underneath it.

Our priority is therefore the opposite.

First:

Can we discover it?

Then:

Can we preserve the evidence?

Then:

Can we normalize it?

Then:

Can we correlate independent observations?

Then:

Can we explain our confidence?

Then:

Can we measure coverage and identify unknowns?

Only after that does the dashboard become meaningful.

Building the foundation for trustworthy cryptographic migration

Post-quantum migration will eventually involve enormous numbers of systems.

Organizations will need to understand their cryptographic dependencies before they can make intelligent migration decisions.

That means the industry needs more than another list of algorithms.

It needs visibility, evidence, provenance, normalization and confidence.

That is what we are building with Sirraya CBOM.

The vision is deliberately straightforward:

Find cryptography.
       ↓
Preserve the evidence.
       ↓
Normalize what was found.
       ↓
Correlate independent observations.
       ↓
Measure confidence.
       ↓
Understand the cryptographic inventory.
       ↓
Export it through an interoperable CBOM.

And from there, the larger post-quantum migration problem becomes much more tractable.

Because before an organization can answer:

“How do we migrate our cryptography?”

it first needs to answer:

“What cryptography do we actually have — and how do we know?”

That is the problem we are working on now.

Not just discovering cryptography.

Building the evidence layer that makes cryptographic discovery trustworthy.