up:: Migration Architecture MOC

Cryptographic Discovery Tooling

Cryptographic discovery tooling is the set of tools and methods that find where cryptography actually lives across an estate so it can be recorded in a CBOM and migrated. Where discovery is the activity and the CBOM is the ledger it fills, the tooling is the instrument set that does the finding: source and binary scanners that read the code, network and traffic discovery that watches the wire, certificate discovery that enumerates the trust material, and structured vendor inquiry that reaches the cryptography a scan can never see. No single category covers a real environment, so a defensible pass layers several and grades what each one produces.

The short version:

• The tooling splits into four categories that each see a different slice: source and binary scanning, network and traffic discovery, certificate discovery, and vendor inquiry.
• Source and binary scanners read what the code contains: library calls, hardcoded parameters, and key-management patterns that never show up in a live handshake.
• Network and certificate discovery read what the estate presents on the wire: negotiated cipher suites, protocol versions, and the certificates in every trust store.
• Vendor inquiry reaches the rest, because vendor-controlled cryptography is invisible to an internal scan and only surrenders its details to a structured questionnaire.
• Every tool feeds the same CBOM, and every finding carries an evidence grade, because a scan proves more than a datasheet and the CBOM has to record which is which.

Think of it as the survey kit for re-keying a very large building. One instrument reads the blueprints (the source), another walks the halls testing which doors are locked and how (the network), a third opens every key cabinet and logs what is inside (the certificates), and the last one phones the contractors who installed locks nobody documented (the vendors). No single instrument maps the whole building, and the tooling landscape for cryptography works the same way.

What are the categories of cryptographic discovery tooling?

Discovery tooling sorts into four categories by where it looks, and a complete pass uses all four because each one sees a different part of the estate:

Category	Where it looks	What it finds	What it misses
Source and binary scanning	Application code, dependencies, compiled binaries	Library calls, hardcoded algorithms and parameters, key handling	Runtime configuration and what a server actually permits
Network and traffic discovery	Live connections, TLS and SSH handshakes	Negotiated cipher suites, protocol versions, key sizes in use	Permitted-but-uninvoked fallbacks, at-rest and code-signing crypto
Certificate discovery	Certificate stores, PKI, TLS endpoints	Signature and key algorithms, key sizes, expiry, chain structure	Cryptography outside the certificate world
Vendor inquiry	Third-party products and managed services	Cryptography inside vendor-controlled surfaces	Nothing verifiable without an artifact; results are asserted

The categories overlap on purpose. A cipher suite found on the wire should also appear in the config a source scan reads, and a mismatch between the two is itself a finding. The reason to run all four rather than pick a favorite is that each covers a blind spot in the others, and the estate that only gets scanned one way is the estate that discovers new vulnerable systems all the way through the migration.

What tools do source and binary scanning?

Source and binary scanners read the artifacts of a system rather than its live behavior, so they surface cryptography that a handshake never reveals: a hardcoded key, a call to a broken hash inside a library, an algorithm baked into a firmware image. Two families do this work:

1. Cryptographic static analysis of source and dependencies. A scanner walks the codebase and its dependency tree for calls into cryptographic libraries, flagging the algorithm, the parameters, and often the key-management pattern around them. Representative examples include IBM’s open-source CBOM Toolkit (cbomkit) and its underlying Sonar-based scanner, which parse source for cryptographic usage and emit a CycloneDX CBOM directly.
2. Binary and firmware analysis. Where source is unavailable, a binary analyzer inspects compiled objects and firmware images for cryptographic constants, characteristic instruction patterns, and linked crypto libraries, which is how you find cryptography in a shipped appliance or an embedded device you cannot recompile.

The strength of this category is that it reads what the code contains rather than what it happens to do under one probe, so it catches at-rest encryption, code-signing routines, and internal service cryptography that never touches an external port. The limit is the mirror image: source shows what is written, not what a deployed instance is configured to permit, so a source scan is a strong layer and a weak whole, and it belongs alongside network and configuration evidence rather than instead of it.

Source: OWASP / IBM, “CBOM Toolkit (cbomkit),” github.com/PQCA/cbomkit; CycloneDX, “Cryptography Bill of Materials,” cyclonedx.org/capabilities/cbom.

What tools do network and certificate discovery?

Network and certificate discovery read what an estate presents on the wire and in its trust stores, which makes them the fastest way to get a first picture of the transport-layer cryptography. The common tools:

1. TLS configuration scanners. Tools like sslyze and testssl.sh open connections to an endpoint and report the negotiated cipher suites, protocol versions, key sizes, and certificate details, which enumerates the perimeter cryptography quickly and repeatably. Nmap’s ssl-enum-ciphers script does the same at scan scale across many hosts.
2. Certificate discovery and inventory. Certificate-management platforms and certificate-transparency queries enumerate the certificates across an estate, exposing the signature algorithm, the public-key algorithm and size, the validity window, and the chain structure, which is exactly the material a CBOM needs for its PKI entries.
3. SSH and other protocol scanners. Host-key and key-exchange scanners inventory the algorithms permitted by SSH, IPsec, and similar services, extending the network view past the web tier.

The value here is speed and breadth: these tools sweep thousands of hosts and return structured, verifiable evidence, a captured handshake or an exported certificate, that grades as verified in a CBOM. The known weakness is that a network probe sees only what a server negotiates when probed, so it misses permitted-but-uninvoked fallbacks. A 2026 corpus study of real-world TLS configurations found that 21.8% of TLS-enabled contexts permitted the obsolete TLS 1.0 or 1.1 as configured even though most would negotiate a modern version in a single handshake, so a scanner-only inventory records the estate as safer than its configuration actually allows.

Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).

Why is configuration extraction the primary transport-layer layer?

Because a configuration file records what a server permits, while a network scan records only what it negotiates under the one condition it was probed, and the gap between those two is where downgrade risk hides. A defensible transport-layer inventory parses the configuration grammar of each termination point (the web server, the load balancer, the proxy) directly, normalizes it into a common schema, and compares it against a quantum-readiness policy that decomposes each cipher suite into its constituent algorithms. That approach captures the permitted-but-uninvoked fallbacks, the leaf-only certificate references that pass permissive clients but fail strict ones, and the session policies a single external probe never exercises.

The practical arrangement is layered rather than either-or: configuration extraction is the primary source of truth for what a server allows, and network and certificate scanning is the runtime cross-check that confirms the deployed behavior matches the configured intent. When the two disagree, the disagreement is a finding worth chasing, because it usually means the running system is not the one the paperwork describes.

Source: Balaji et al., arXiv:2605.17955 (2026).

How does the tooling feed a CBOM?

Every category of tool produces entries that flow into the same CBOM, which is the point of running them: the tools are the collection mechanism, and the CBOM is the normalized record they populate. The connective tissue that keeps this from becoming a pile of incompatible reports is a shared machine-readable format. CycloneDX added a native CBOM schema from version 1.6, so a scanner can emit its findings as CycloneDX components that a vulnerability-management or governance platform ingests without a translation step, and IBM’s cbomkit is built to produce exactly that output.

Two disciplines make the fed-in data trustworthy:

1. Grade every entry by evidence. A captured handshake, an exported certificate, or a parsed configuration file grades as verified, because a technical artifact proves the finding. A vendor datasheet or an architecture diagram grades as documented, because it asserts the finding without proving it, and documented evidence can be wrong when a system does not run the way its paperwork claims.
2. Record a provenance trace on each entry. A derived_from pointer to the exact source file, configuration directive, and line lets a reviewer confirm the entry reflects the system’s real configured behavior rather than a transformation artifact introduced by the tool.

Source: CycloneDX, “Cryptography Bill of Materials,” cyclonedx.org/capabilities/cbom; Balaji et al., arXiv:2605.17955 (2026).

Why isn’t there one tool that finds all the cryptography?

Because the cryptography sits in fundamentally different places that no single instrument reaches, and the categories are defined by exactly those blind spots. A network scanner cannot see the algorithm hardcoded in a firmware image, a source scanner cannot see the fallback a running load balancer permits, a certificate tool cannot see the at-rest encryption on a database, and none of them can see the cryptography inside a vendor’s closed product. The tooling is immature and consolidating, but no current tool provides complete automated coverage, which is why a real discovery pass combines scanners with custom scripts and human review.

The category that no tool can automate away is vendor inquiry. Vendor-controlled cryptography is invisible to internal scanning by construction, so reaching it means sending structured questionnaires and collecting the answers, which grade as documented evidence until the vendor supplies an artifact that proves them. This is a large part of why a thorough inventory is real work rather than a one-click scan, and why a first pass that only runs the automated scanners against internally-managed systems leaves much of the real footprint uncounted. Building the whole picture takes the tooling plus the inquiry plus the judgment to reconcile them, which is the agility program’s foundation and the migration’s first deliverable.

Common misconceptions

1. “One scanner will build our CBOM.” No single tool covers the estate. A network scanner misses at-rest and firmware cryptography, a source scanner misses runtime configuration, and every automated tool misses vendor-controlled surfaces. A defensible pass layers all four categories.
2. “A TLS scan tells us our transport is safe.” A scan reports what a server negotiates when probed, which can hide permitted weak fallbacks. Configuration extraction is the primary transport-layer source of truth, with the scan as a runtime cross-check.
3. “The tools give us verified evidence automatically.” Only the ones that capture a technical artifact do. Vendor questionnaires produce documented evidence that stays unproven until an artifact backs it, and the CBOM has to record the grade on every entry.
4. “Discovery tooling is mature enough to run unattended.” It is growing but still immature, and no tool provides complete coverage without custom scripting, vendor inquiry, and human review to reconcile the categories.
5. “Any output format works.” For the CBOM to integrate with vulnerability-management and governance systems it has to be machine-readable, and CycloneDX 1.6+ is the emerging standard the modern tools emit.

Questions people ask

What is the difference between cryptographic discovery and discovery tooling? Discovery is the activity of finding your cryptography, and tooling is the set of instruments that does the finding. Discovery is the survey, the tooling is the survey kit, and both exist to populate a CBOM.

What tools do I actually start with? For a first transport-layer picture, TLS scanners like sslyze and testssl.sh give fast verified evidence, and certificate inventory gives the PKI view. For depth, a source and dependency scanner such as IBM’s cbomkit surfaces the cryptography inside the code, and vendor questionnaires reach the surfaces no scan can see.

Do these tools produce a finished CBOM by themselves? No. They produce evidence that populates a CBOM, but a complete inventory needs all four categories combined, plus vendor inquiry and human review, because no single tool covers the whole estate automatically.

Can a scanner see cryptography inside a vendor product? No. Vendor-controlled cryptography is invisible to internal scanning, so it takes structured inquiry, and the answers grade as documented evidence until the vendor supplies an artifact.

What format should the tools output? Machine-readable CycloneDX, from version 1.6 onward, which carries a native CBOM schema so the findings feed vulnerability-management and governance platforms without a manual translation step.

Why layer configuration extraction over network scanning? Because a config records what a server permits and a scan records only what it negotiates when probed. A 2026 TLS corpus study found 21.8% of contexts permitted obsolete TLS 1.0 or 1.1 as configured even though a single probe would show a modern version, so configuration extraction is the primary layer and the scan is the cross-check.

---

Everything here is the map, given freely. When your team needs the discovery tools chosen, run, and reconciled into a verified inventory of your own estate, that’s the work I do, and there’s an alignment briefing for it.

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