Mobile Application Discovery

What mobile application discovery means

Mobile application discovery is the process of identifying and describing cryptography used by a mobile application, its packaged artifacts, its execution environment, and the services with which it communicates. The objective is an inventory that explains not only which algorithm or protocol appears in an artifact, but also where it is used, what data or connection it protects, which implementation provides it, and which operational dependencies surround it. This is consistent with the broader objective of cryptographic discovery: creating visibility into how systems use cryptography and identifying cryptography in applications, associated libraries, network protocols, and development pipelines.12

The scope is broader than a search for recognizable algorithm names. A useful discovery effort considers application source and binary code, platform cryptographic APIs, native code, cryptographic libraries, certificates, keys and keystores, local storage, network protocols, configuration, third-party libraries, update artifacts, and server dependencies. The inventory should preserve relationships among these elements. For example, a certificate may identify a server connection, while a library or platform API may explain how that connection performs cryptographic operations.21

Static and dynamic analysis

Static analysis examines application source code and binary code without relying on a particular runtime execution path. Its purpose is to reason about possible program behavior across inputs and execution environments. For mobile applications, this can include the packaged application, bytecode, native libraries, embedded resources, configuration, and available source or build materials. Android binary applications, for example, include bytecode that can be analyzed without hardware support using emulated or virtual environments. Static analysis is therefore well suited to broad inventory coverage and to locating code paths that a test session may never execute.3

Dynamic analysis executes the application with selected use cases and observes runtime behavior. It can reveal which cryptographic APIs, libraries, protocols, certificates, storage operations, and service calls are actually exercised in a representative session. It can also show behavior that is difficult to infer confidently from code alone, such as conditional configuration or operations reached only after authentication. Dynamic analysis has a material limitation: the number of possible input cases may be large, and even systematic reductions such as combinatorial testing do not make complete execution coverage automatic. The evidence explicitly states that dynamic analysis is unlikely to provide 100 percent code coverage.3

The two methods should be treated as complementary rather than interchangeable. Static analysis can over-approximate behavior by identifying code that is present but inactive, unreachable, or used only under a condition not encountered during testing. Dynamic analysis can under-approximate behavior by missing untested flows, platform branches, optional modules, or server responses. A defensible process records the method used, the artifact or build examined, the platform version and configuration, the test cases executed, and the limitations that affect interpretation.3

What to examine in the application

Begin with an identified application artifact. Record the package identity, version, signing information available from the package, build provenance, and configuration variant. A unique application reference and software identification and version information are relevant to mobile application assurance. Signed packages are important evidence of the artifact being examined, but a signature establishes package integrity or provenance within its trust model; it does not, on its own, describe every cryptographic operation performed by the application.34

Inspect managed source or bytecode and native libraries separately. Search for direct cryptographic operations, calls to platform services and application programming interfaces, references to cryptographic libraries, certificate-processing logic, random-bit generation, key-generation or key-loading paths, and configuration that selects algorithms or protocols. Mobile assurance requirements specifically identify cryptographic key functionality, cryptographic operations, random bit generation, X.509 functionality, supported services and APIs, and use of third-party libraries as relevant functional areas.3

Native code deserves explicit treatment because code executed directly on a mobile device’s CPU may not be represented in the same way as managed application code. The discovery record should distinguish an operation implemented directly in application code from one delegated to a platform API or external library. That distinction helps reviewers determine which implementation, validation status, update path, and operating-system dependency must be followed when assessing the finding.3

Obfuscation and packaging can make interpretation harder. A string or symbol search may fail when names, control flow, or constants are transformed, while a detected library may be present without being used in the tested product path. Discovery should therefore correlate multiple signals: code and binary inspection, package contents, configuration, execution traces, network observations, and dependency records. When a result cannot be confirmed, report it as an observation or candidate rather than silently converting it into a confirmed cryptographic asset.3

Network behavior, certificates, and server dependencies

Network discovery should identify the protocols used to protect communications, the endpoints or service roles involved, the certificates presented or validated, and the application code or platform service responsible for the connection. Cryptographic discovery guidance calls for identifying quantum-vulnerable algorithms in network protocols and understanding which systems and protocols move or provide access to sensitive and critical datasets. A mobile inventory should consequently connect a network observation to its application feature and to the server dependency that completes the communication path.

Certificate handling should be examined as behavior, not merely as a list of certificate files. Record certificate subjects or roles where available, validity information, trust or path-validation behavior, and the application or platform component that performs validation. Certificate inventories are intended to monitor validity periods, detect algorithms and key lengths that are no longer secure, and support replacement and incident response. RFC 5280 also cautions that retrieved certificate or revocation data must be validated as properly formed and describes risks associated with certificate and revocation-data dependencies.

Certificate pinning, when encountered, should be recorded as a validation behavior and linked to its configuration and update mechanism. The cited evidence establishes the importance of certificate validation and communications protection, but it does not provide a general rule that every application must or must not pin certificates. Discovery should therefore document what the application does, under which configuration and platform version, and whether the observed behavior is confirmed, inferred, or unresolved.

Server dependencies are part of the application’s cryptographic context. A client may rely on server certificates, protocol negotiation, session establishment, key management, authentication services, centralized authorization, or other external modules. TLS 1.3, for example, can use a previously established pre-shared-key identity in a later handshake, and the selected use of pre-shared keys affects forward-secrecy properties depending on the key-exchange arrangement. A client-side observation should not be interpreted without preserving the relevant server-side protocol and configuration context.

Local storage, keystores, backups, and third-party components

Local storage analysis should look for cryptographic keys, certificates, keystores, encrypted application data, credential material, backups, and configuration that controls their location or protection. The inventory should distinguish a key reference from key material and should record lifecycle context such as generation, storage, use, backup, recovery, revocation, and destruction where that information is available. NIST key-management guidance defines key management across these lifecycle activities and describes a key-management system as handling metadata and functions such as generation, distribution, storage, backup, archive, recovery, use, revocation, and destruction.

Backup behavior requires particular care. Determine whether application data, configuration, certificates, or key-related material is included in a backup path, excluded, or controlled by a platform or service policy. Do not treat a detected private key as ordinary inventory metadata: NIST guidance states that private keys associated with certificate public keys should not be included in a certificate inventory unless that inventory is also used for permitted key backup or archiving. Testing should avoid copying or exposing sensitive material unnecessarily.

Third-party SDKs and libraries should be inventoried with their names, versions, hashes or other available identifiers, declared relationships, and observed cryptographic role. An SBOM is described as a nested inventory of the ingredients that make up software applications and systems, and its minimum elements include component hashes, dependency relationships, tool information, timestamps, generation context, and known unknowns. These records help distinguish application-owned code from inherited or externally maintained cryptography and support follow-up with vendors when embedded cryptography is not visible.

The evidence identifies an important discoverability limitation: discovery tools may not identify cryptography embedded internally within products. Organizations should ask vendors for lists of embedded cryptography. For mobile applications, this means a clean static result is not proof that no cryptography exists, particularly when a library, SDK, native component, platform service, or server dependency performs the operation outside the most obvious source path.

Designing representative and privacy-safe testing

Dynamic testing should use representative, authorized use cases that exercise meaningful application features and communication paths. Record the inputs, account or role conditions, platform and application versions, configuration, network conditions, and services reached. Because dynamic testing cannot guarantee complete coverage, use static results and dependency evidence to identify flows that were not exercised and to prioritize additional cases. The selection of cases should be proportionate to the application’s role and the sensitivity of the data it handles.3

Testing should be performed in an isolated environment with test data and controlled accounts. The cited evidence supports considering the digital environments in which a product operates, its backend and companion applications, external dependencies, and potential misuse or compromise paths. It does not prescribe a particular rooted or instrumented mobile setup. Accordingly, any rooted, emulated, virtualized, or instrumented environment should be documented as a test condition rather than assumed to represent every production device or platform configuration.

Privacy-safe testing means minimizing collection of personally identifiable information and sensitive payloads, using synthetic records where possible, restricting captured traces, and protecting any credentials, certificates, tokens, or keys encountered during authorized testing. Mobile application requirements include user consent for transmission of personally identifiable information, while secure software and cybersecurity practices emphasize protecting information and managing dependencies. These requirements support a controlled evidence-handling process, but the cited passages do not define a complete privacy testing standard.

Maintain a finding status such as confirmed, probable, candidate, not observed, or unable to determine. A false positive can arise when a library or code path is present but unused, when a sample configuration differs from deployment, or when a static indicator is mistaken for runtime behavior. A false negative can arise when a path was not executed, embedded cryptography was not discoverable, or a server-side dependency was outside the test boundary. These are methodological limitations, so the report should preserve uncertainty instead of overstating precision.3

Turning observations into a useful inventory

A useful record connects each observation to an application version and artifact, component or code location, cryptographic function, algorithm or protocol when known, implementation or provider, key or certificate relationship, data or transaction protected, platform and configuration, external dependency, evidence method, confidence, and owner for follow-up. It should also record unknowns. This structure makes the inventory actionable for cryptographic risk assessment, certificate and key lifecycle work, software supply-chain review, and future algorithm transitions.

Prioritization should consider both the cryptography and what it protects. CISA, NSA, and NIST state that an inventory of quantum-vulnerable technology and the criticality of associated data enables organizations to begin risk assessment and prioritize migration. The same guidance recommends understanding which systems and protocols move or access sensitive and critical datasets and correlating the cryptographic inventory with existing asset, identity, credential, access, endpoint, and diagnostic inventories.

For development teams, discovery should be connected to the software lifecycle. The cited DevSecOps evidence describes source repositories, automated builds, static and dynamic vulnerability analysis, software composition analysis for attached libraries, packaging, deployment, configuration, and human review. Repeating discovery for release candidates and material dependency or configuration changes can preserve the relationship between the analyzed artifact and the deployed application, although the evidence does not prescribe a specific mobile release cadence.

Finally, treat the inventory as maintained information rather than a one-time scan. Certificates change, application versions change, libraries change, server configurations change, and migration work can replace cryptographic implementations or protocols. Crypto-agility guidance describes the need to address algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. A mobile application record should therefore retain dates, versions, evidence, dependencies, and unresolved questions so that later reviews can determine what changed.

Conclusion

Mobile application discovery is best understood as a correlated inventory exercise covering artifacts, code, platform services, native components, runtime behavior, communications, certificates, storage, dependencies, configurations, and server relationships. Static and dynamic analysis provide different kinds of evidence and both have limitations. Careful scope definition, representative authorized testing, privacy-safe evidence handling, explicit uncertainty, and versioned records make the results more useful. The finished inventory can support cryptographic risk assessment and migration planning, but it remains one input to—not a substitute for—a complete mobile security assessment.13