Third-party Library Discovery

What third-party library discovery means

Third-party library cryptographic discovery focuses on cryptographic algorithms, protocols, implementations, and related services inherited through software that an organization did not develop entirely itself. The relevant object may be a directly selected library, a framework, middleware, module, SDK, package, container base layer, vendor binary, or another component used to assemble an application. NIST’s secure software guidance treats libraries, modules, middleware, and frameworks from commercial, open-source, and other third-party developers as software components that should be acquired and maintained with attention to expected use and provenance.123

The discovery question is therefore broader than “which cryptographic package did a developer add?” A component can arrive through a dependency relationship, a build artifact, a container image, a platform, or a product cited by another organization. Cloud-native applications commonly consist of loosely coupled microservices, often implemented as containers, together with service infrastructure that provides security services such as secure communication, authentication, and authorization. That architecture creates multiple places where inherited cryptography may reside.3

Use multiple evidence layers

No single artifact reliably answers every discovery question. A practical program combines prebuild or source records, build-time records, postbuild or analyzed SBOMs, source inspection, binary analysis, container and image inspection, and runtime observation. CISA distinguishes prebuild or source SBOMs from build or build-time SBOMs and analyzed or postbuild SBOMs generated from binary analysis. The generation context matters because each form describes a different point in the software lifecycle. []42

Dependency manifests and lockfiles can establish what a build declares or resolves, while package metadata can add identifiers, versions, hashes, licenses, and producer information. In an evidence-driven process, these records should be compared with the released package, executable, firmware, or image actually deployed. CISA’s minimum elements include the component name, component version, software identifiers, component hash, software producer, dependency relationship, SBOM author, tool name, and timestamp.4

Source and binary evidence complement dependency records. Source analysis can expose calls, wrappers, embedded code, and cryptographic services that metadata does not describe. Binary analysis can identify components that are present in a release even when source or build records are incomplete. The NIST cryptographic-discovery demonstration describes automated tools that should identify algorithms in hardware and software modules, libraries, and embedded code, while also recognizing that discovery tools may not identify embedded cryptography inside products.

Map direct, transitive, vendored, and dynamic components

A direct dependency is selected by the application or build, but cryptographic exposure often travels through transitive dependencies: components required by another component. CISA states that an SBOM should include all components that make up the target software, including transitive dependencies, with no minimum depth. If multiple instances of a component have different metadata, each instance should be listed separately with the appropriate dependency relationship. []4

The graph should also account for code copied or maintained inside a product, forks that diverge from an upstream project, plugins loaded by an application, and components downloaded after installation or during execution. These cases can weaken the assumption that a package index or a top-level dependency file describes the complete deployed software. The source set supports a conservative approach: compare declared composition with the components found in build outputs, binaries, images, and running systems, and document gaps rather than silently treating them as absent.42

Container images require special attention because an image is a collection of packaged files and may include components inherited from base layers or other third-party images. NIST warns that the full provenance of third-party base layers may not be known and recommends trusted images and registries, with each image discretely identified by cryptographic signature. Image-layer analysis should therefore preserve the relationship between the final image, its layers, and the component or library found in each layer.5

Dynamic downloads and runtime modules require a separate observation path. A component may be absent from a source snapshot but appear in a deployed environment, or it may be present in an image without ever being loaded. Runtime evidence can show which modules, services, protocols, or cryptographic operations were observed while an application ran. The NIST demonstration describes dynamic capture of cryptographic services, engines, and algorithms during application execution and describes that information as useful for inventory and audit.2

Record identity, version, and provenance

Component identity must be precise enough to distinguish similar names, releases, and instances. At minimum, preserve the producer-assigned name and version, software identifiers, and—when available—the component hash. Record who produced the component, who generated the evidence, which tool was used, and when the record was updated. These fields allow a finding to be tied to a particular artifact rather than to an ambiguous library name. []4

Provenance answers where a component came from and how it entered the artifact: an approved repository, supplier package, source build, base image, internal fork, or another route. NIST recommends obtaining and analyzing provenance information such as an SBOM, source composition analysis, or binary software composition analysis for each software component. It also recommends retaining older component versions until transitions from those versions have completed successfully.1

Unsupported dependencies deserve an explicit status. A dependency that no longer receives support, cannot be rebuilt, or lacks reliable supplier information is not equivalent to a verified current component. Legacy digital equipment is associated with a significantly higher likelihood of vulnerabilities and can be difficult to remediate when coordination with customers is required. For software components, the operational conclusion should be recorded as a risk and uncertainty, not hidden by assigning an apparently complete version record. []7

Duplicate implementations should remain distinct when they differ in version, metadata, provenance, or deployment location. CISA specifically requires separate listing for multiple component instances with metadata differences. Deduplicating them into one library record can obscure that two applications, image layers, or services carry different cryptographic implementations and may require different remediation paths. []4

Separate presence, reachability, and use

A library found in a manifest, package, binary, or image demonstrates presence in that evidence scope; it does not by itself demonstrate that the application can reach the library’s cryptographic code or that the code executed. Conversely, a missing dependency record does not prove that cryptography is absent: embedded code, incomplete records, dynamically obtained components, and product-internal implementations can remain undiscovered. This distinction is central to interpreting discovery results.62

Reachability is a stronger statement about a path from an application or service to a component or cryptographic function. Static source or binary analysis can provide evidence of references and possible paths; configuration and deployment analysis can refine whether the relevant feature is enabled. Runtime observation provides evidence that a path was exercised in the observed conditions, but it is still bounded by the tested workload, configuration, and time window. The cited NIST material presents static analysis and dynamic capture as complementary discovery approaches rather than interchangeable proofs.62

Cryptographic use also has context. A cryptographic inventory should identify algorithms used in modules, libraries, and embedded code, as well as algorithms supporting key establishment and management and protecting data at rest, in transit, and in use. It should then identify where vulnerable cryptography protects the most sensitive or critical datasets and estimate the length of protection required.26

An SBOM is not a complete cryptographic-use record

An SBOM is a digital record of software components and supply-chain relationships used to build software. Its value is composition visibility: it can show what components and transitive dependencies are associated with a target artifact, and it can support risk decisions when the relevant component is listed. CISA also states that a new build or release should have a new SBOM and that corrected or newly discovered component details should result in a revised SBOM.24

An SBOM does not necessarily state which cryptographic algorithms a component implements, which functions an application calls, which configuration enables a protocol, which keys or certificates are involved, which data is protected, or whether a present component was exercised. Those questions require cryptographic discovery and correlation evidence. A CBOM extends an SBOM with an object model for cryptographic assets and their dependencies, but the cited NIST preliminary draft says the CBOM model is still developing and may not address every organizational use case.2

Incomplete SBOMs must be treated as incomplete. CISA says that if dependencies are not listed, known unknowns should be identified, and that the default interpretation should be that the data is incomplete. The author should distinguish information unknown to the author from information intentionally redacted, while recipients should have a process to ask about redacted security-related information. []4

Correlate findings to applications and suppliers

A useful discovery record links the component or implementation to the application, service, host, image, firmware, deployment, and relevant business or data asset. This correlation converts a library finding into an actionable inventory item. CISA, NSA, and NIST recommend correlating cryptographic inventory with existing asset, identity and access, endpoint, and diagnostic inventories, and emphasize that organizations may be unaware of the breadth of application and functional dependencies on public-key cryptography.

Supplier evidence is necessary where inspection cannot see inside a product or dependency. Discovery tools may fail to identify cryptography embedded internally within products, so organizations should ask vendors for lists of embedded cryptography. Procurement and review processes should also obtain provenance information for each component and assess the component in the context of its expected use; a substantially different future use warrants another review.

For containers and other packaged deployments, correlate the final deployed image with its trusted source, signature, registry, layers, included libraries, and running workload. NIST recommends centrally controlling trusted images and registries and enforcing that hosts run only images from the trusted set. This does not replace cryptographic analysis, but it strengthens the provenance boundary around the artifacts being analyzed.51

1. Collect dependency, package, build, release, source, binary, image, and runtime records for the target application or product.
2. Normalize component identity and preserve versions, hashes, producers, dependency relationships, generation context, timestamps, and provenance.
3. Expand direct dependencies through transitive relationships and separately record forks, vendored code, plugins, image layers, and dynamically obtained components.
4. Inspect source, binaries, packages, and images for cryptographic implementations; use runtime observation where feasible to record exercised behavior.
5. Assign an evidence state that distinguishes presence, possible reachability, observed use, and unknown or redacted information.
6. Correlate each result to applications, services, deployed assets, protected data, and suppliers; record unsupported components and duplicate implementations as separate risk items.
7. Refresh records when a build or release changes, and revise them when component details are corrected or newly discovered.

Limitations and review questions

Discovery is bounded by the coverage and quality of its inputs. A source SBOM can differ from a release artifact; a binary scan can identify components without proving execution; runtime observation can miss code paths not exercised; and a supplier may need to disclose embedded cryptography that tools cannot see. The evidence state should therefore include collection date, artifact or environment scope, tool or supplier basis, and known gaps. []

Reviewers should ask: Is the component identity unambiguous? Which version and artifact were examined? Is the component direct or transitive? What is its provenance? Is it present only, potentially reachable, or observed in use? Is the dependency unsupported, duplicated, forked, vendored, dynamically obtained, or embedded? Which application and sensitive data does it relate to? What remains unknown or redacted? These questions keep the inventory useful for remediation and future cryptographic change. []

Conclusion

Third-party library discovery is a layered evidence process, not a package-name lookup. Build a complete dependency graph, preserve identity and provenance, inspect both source and delivered artifacts, observe runtime behavior where possible, and correlate findings to applications and protected assets. Use SBOMs as an important composition record, but supplement them with cryptographic and operational evidence because presence is not the same as reachability or use. Explicitly retain uncertainty, unsupported dependencies, duplicate implementations, supplier gaps, and embedded-cryptography limitations so the resulting inventory remains defensible and actionable. []2