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 the open-source 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: CBOMkit project, “A toolset for dealing with Cryptography Bill of Materials (CBOM),” github.com/PQCA/cbomkit (the repository now presents itself as cbomkit/cbomkit; its CBOMkit-hyperion Sonar Cryptography Plugin component is an open-source tool developed by IBM, and the project page carries no OWASP attribution); OWASP CycloneDX, “Authoritative Guide to CBOM,” 2025, cyclonedx.org/capabilities/cbom, for the BOM phase model that separates a source-side inventory from an Operations BOM covering “runtime environments, configurations, and additional dependencies.”

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 and may cause chain-validation failures on 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 the 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 the 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.

---

The precedent

The fifth labor Eurystheus set Heracles was to carry out the dung from the cattle-yards of Augeas, king of Elis, in a single day. Augeas had many herds and the yards had been accumulating for thirty years. Apollodorus records that Heracles never mentioned Eurystheus at all. He went to Augeas, offered to clear it in one day in exchange for a tithe of the cattle, and took Augeas’s son Phyleus as witness to the bargain. Then he made a breach in the foundations of the yard, cut an outlet on the far side, and diverted the Alpheus and the Peneus through the building. Eurystheus later refused to count the labor, on the grounds that Heracles had been paid for it.

Apollodorus, Bibliotheca II.5.5

The moral: the task was genuinely impossible by the obvious method, and the answer was to change the mechanism rather than to work harder at the shovel.

A cryptographic inventory built by interviewing teams and reading documentation produces a partial, stale picture at enormous cost, and the estate keeps growing while the survey runs. Discovery that finishes is instrumented: traffic capture on the wire, certificate and key-store enumeration, binary and dependency scanning, and continuous collection rather than a campaign. The scale is not a resourcing problem to be solved by adding analysts. Eurystheus was not wrong that the labor had been done differently from how he intended it. It had also been done, in a day, which is the part the record kept.

---

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 a working session with your team.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.