Binary Discovery

What binary discovery covers

Binary cryptographic discovery is a focused form of software and asset analysis. Its subject is the artifact that can execute or be deployed: an application executable, shared or static library, firmware image, package, Java archive, or container layer. The purpose is to identify evidence that cryptography exists, determine where it appears, and connect it to the asset and software supply chain. The cited discovery demonstration explicitly separates executable and nonexecutable file objects. Its executable examples include application binaries, cryptographic libraries, and Java archives; its nonexecutable examples include keystores and formats containing public or private asymmetric keys, such as X.509 certificates, OpenPGP keys, OpenSSH keys, and PKCS formats.1

This scope complements, rather than replaces, source-code and runtime discovery. Static analysis examines source and binary code and attempts to reason about possible runtime behavior, whereas dynamic analysis executes a program with selected inputs and observes what happens. Static analysis can therefore examine paths that a test did not trigger; dynamic analysis provides direct execution evidence but is unlikely to achieve complete code coverage.2

What evidence can be found

A binary assessment can begin with symbol and import inspection. Exported symbols, imported functions, API references, and linkage records may reveal calls to cryptographic services or libraries. Where symbols are absent, the assessor can use recognizable signatures, constants, instruction sequences, and disassembly to identify likely implementations or call sites. Library fingerprinting can help distinguish a bundled cryptographic implementation from a system-provided dependency. These techniques produce indicators whose strength depends on the artifact, architecture, compiler output, and available reference patterns; they should be recorded as evidence rather than treated as infallible identification.12

Package metadata adds context that machine-code inspection alone may not provide. Package names, versions, manifests, dependency declarations, archive contents, and software identifiers can connect a binary to a component and a release. A component hash can identify the exact software component when the original artifact is available; if the SBOM author does not have access to that artifact, the cited SBOM guidance says a component hash should not be included. Provenance should also identify the producer, and unknown provenance should be explicitly recorded when traceability is unavailable.34

Embedded certificates, public keys, private-key containers, trust material, and certificate chains are especially important because they may expose cryptographic material that is not apparent from imports. Certificate processing must be interpreted carefully: certificate profiles define encoding and validation procedures, and implementations are not required to use one particular cryptographic algorithm. A certificate’s presence therefore identifies material and a relationship to investigate; it does not prove that a particular cryptographic operation is performed by the binary in every execution.15

Why binary analysis is difficult

Stripped binaries remove or reduce symbol information, making names and direct API interpretation unavailable. Static linking can place library code inside the application, so a finding may identify a bundled implementation rather than a separately deployed library. Dynamic linking can instead leave the binary dependent on a library that is resolved only in a target environment. The same cryptographic behavior may consequently appear as local code, an import, a package dependency, or a runtime-loaded module. These are distinct evidence forms and should not be collapsed into a single unqualified finding.46

Obfuscation, packing, optimization, dead-code elimination, encrypted or password-protected key stores, and incomplete extraction can reduce fidelity. The cited discovery demonstration specifically notes that password-based encryption of private-key formats may affect discovery results. It also describes its tool list as a demonstration scope based on capabilities exercised in a laboratory environment and warns that individual platforms may have extended capabilities. Accordingly, absence of a finding means “not observed under the method and artifact conditions,” not necessarily “absent from the software.”1

Architecture differences matter because instruction sets, calling conventions, binary formats, firmware layouts, and compiler transformations change how the same operation appears. An analyzer validated for one architecture or file format may not provide equivalent evidence for another. Java archives and bytecode may be analyzed without hardware support in emulated or virtual environments, while native code and firmware may require architecture-aware parsing and disassembly. Coverage and parser support should therefore be part of the finding record.2

Confidence scoring and provenance

Confidence scoring makes the difference between direct evidence and inference visible. A practical record can distinguish a direct artifact observation, a strong signature or fingerprint match, a contextual package indication, and an unresolved hypothesis. The score should describe confidence in the stated claim—for example, “this artifact contains a reference consistent with algorithm X”—rather than silently upgrading it to “algorithm X securely protects data.” The cited sources support inventories that provide visibility into how an organization leverages cryptography and software-development practices that obtain provenance information through SBOM, source-composition analysis, or binary software-composition analysis.74

Every finding should preserve the artifact identity and acquisition context: file or image identifier, version where available, cryptographic hash when supported, package or component identity, producer, architecture, layer or path, analysis timestamp, tool and method, matched evidence, and limitations. Release-integrity guidance recommends making verification information available to acquirers, including cryptographic hashes and code-signing information; container guidance likewise recommends validating image integrity with hashes and digital signatures before runtime. These controls do not replace discovery, but they help establish that the analyzed artifact is the artifact intended for deployment.483

Unknown or incomplete provenance is itself a meaningful result. If the producer cannot be clearly identified, the SBOM guidance says the component should be marked as having unknown provenance. That status should lower confidence in conclusions about ownership, patch responsibility, and deployment equivalence, while prompting collection of build records, release metadata, package manifests, or supplier information.34

Correlating binary findings

Binary evidence should be correlated with source and runtime evidence before a migration or remediation decision. Source records can explain intended use, algorithm selection, parameters, feature flags, and error handling. Runtime observation can show whether an identified routine is reached, which configuration is active, which protocol is negotiated, and which keys or certificates are actually loaded. Static and dynamic analysis have different tradeoffs, so using both can reduce the risk of treating either a dormant code path or a narrow test result as the complete operational picture.21

Correlation should also include deployment context. A cryptographic library may be bundled in an executable, cited by an operating system, loaded by a container layer, or selected through a plugin mechanism. For containers, image identity, registry provenance, signatures, layer contents, and runtime controls are relevant. NIST container guidance describes validating image signatures before execution and maintaining trusted image repositories; those measures help connect a discovery result to the image that actually runs.8

Certificates and trust anchors require additional care. TLS guidance states that implementations are responsible for verifying certificate integrity and should generally support revocation messages; applications should also enforce minimum and maximum key sizes. Certificate-profile guidance notes that revocation information can affect the assurance placed in a certificate. A binary finding that identifies an embedded certificate should therefore lead to checks of validity, trust-anchor handling, revocation behavior, replacement procedures, and deployment scope—not merely an algorithm label.95

A practical binary discovery workflow

1. Define the inventory boundary: applications, libraries, firmware, packages, archives, container images and layers, keystores, certificates, and other relevant objects.
2. Acquire and preserve artifacts with release, package, producer, architecture, version, hash, and signature information where available.
3. Classify objects as executable or nonexecutable and record the path, image layer, package, or deployment unit in which each object was found.
4. Inspect symbols, imports, linkage, recognizable signatures and constants, disassembly, embedded objects, package metadata, and library fingerprints.
5. Extract and classify certificates, public keys, private-key containers, trust material, and references to cryptographic services without exposing secret material unnecessarily.
6. Assign confidence to each observation and record the exact evidence location, method, parser coverage, and known limitations.
7. Correlate findings with source, SBOM or other provenance records, build and release information, configuration, deployment context, and runtime observations.
8. Prioritize follow-up according to asset criticality, data-protection period, exposure, algorithm or key concern, reachability, and confidence; preserve unresolved uncertainty for later review.

The workflow should produce an inventory that supports action rather than a collection of unexplained matches. Quantum-readiness guidance recommends an inventory of quantum-vulnerable technology and associated data criticality to begin risk assessment and prioritize migration. The same guidance includes applications and associated libraries among the assets to inspect, while also identifying software and firmware involved in creating and validating digital signatures. Binary findings can therefore be valuable inputs to migration planning when they are tied to the asset, use, and criticality rather than counted as isolated algorithm occurrences.7

Common misinterpretations

• “The binary imports a cryptographic function, so every data path is protected.” An import shows a dependency or reference, not universal reachability or correct use.
• “No symbol was found, so no cryptography exists.” Stripping, static linking, obfuscation, architecture, and parser limitations can hide evidence.
• “A certificate is present, so authentication is correctly enforced.” Validation, revocation, trust-anchor selection, and key-size policy still require examination.
• “The package name identifies the exact deployed code.” Component identity and exact artifact identity require reliable version, hash, producer, and provenance information.
• “A vulnerable algorithm finding proves immediate compromise.” Risk depends on use, exposure, protected data, key or signature purpose, configuration, and operational context.
• “A clean static result proves runtime safety.” Static and dynamic methods provide different coverage and neither should be treated as an unrestricted security guarantee.

Evidence and scope notes

This article uses the cited sources as evidence for discovery scope, static and dynamic analysis tradeoffs, provenance, software and image integrity, certificate handling, and cryptographic inventory practice. The principal discovery source is NIST SP 1800-38B Preliminary Draft, published December 1, 2023; it describes a functional test plan and a laboratory demonstration, and expressly cautions that individual discovery platforms may have extended capabilities. That preliminary status and stated demonstration scope are limitations on how broadly its specific examples should be generalized.

The article does not prescribe a particular commercial tool, claim that a cited source defines a universal binary-discovery taxonomy, or assert that any finding alone establishes secure cryptographic use. Where the evidence discusses certificates, code signing, SBOMs, containers, or runtime analysis, those passages are used to explain corroboration and assurance boundaries rather than to turn a discovery observation into a compliance conclusion. [claim-source-status

Conclusion

Binary discovery turns compiled and packaged software into inspectable evidence for a cryptographic inventory. Its value comes from combining multiple signals—imports, symbols, signatures, disassembly, metadata, fingerprints, certificates, and key containers—with exact artifact identity and provenance. Because stripped code, linking choices, obfuscation, architecture, protected key material, and incomplete coverage can conceal or distort evidence, findings should carry explicit confidence and limitations. Most importantly, algorithm identification is a starting point: source, deployment, and runtime correlation are needed to determine how cryptography is actually used and what action is justified.1274