What is the difference between static and dynamic analysis in mobile SBOM generation?

Static analysis inspects code or compiled artifacts to identify declared or embedded components, while dynamic analysis observes the app while it runs on real devices. For mobile SBOMs, using both matters because static methods reveal inventory and dependency structure, and dynamic methods uncover live endpoints, geolocation behavior, and runtime vulnerabilities that source inspection may miss.

Static analysis vs dynamic analysis in mobile SBOM generation

Static analysis is the inventory-first view: it inspects source code, bytecode, or packaged artifacts to identify declared dependencies, embedded libraries, certificates, strings, and other build-time signals. Dynamic analysis is the runtime view: it observes the app in use on a device or emulator to see what it actually loads, contacts, or executes. For mobile SBOM generation, the distinction matters because each method exposes different parts of the software bill of materials.

What static analysis can tell you that runtime observation cannot

Static analysis is strongest when you need repeatable component inventory and dependency structure. It can detect packaged SDKs, bundled frameworks, hard-coded endpoints, embedded secrets, and other artifacts present before the app runs. That makes it useful for baseline SBOM assembly, release gating, and comparing what was intended to ship versus what actually reached the store. A static pass also scales well across many builds because it does not depend on device behaviour or test coverage.

Static analysis is limited by what is visible in code and artifacts. It may miss code loaded conditionally, downloaded later, assembled at runtime, or hidden behind obfuscation, reflection, native libraries, or split delivery. It can also overstate exposure when a dependency is packaged but never exercised in practice. In mobile environments, that gap is important because the shipped app package is often only part of the real execution surface.

Why dynamic analysis adds SBOM value on mobile

Dynamic analysis shows the app as an operating system and network stack would see it: live API calls, actual third-party service use, runtime code paths, geolocation requests, permission-driven behaviour, and unexpected network destinations. For mobile SBOM work, this can uncover dependencies that static inspection misses, especially if the app resolves them lazily, loads them from remote configuration, or activates them only for certain users or regions. It also helps validate whether a declared dependency is still used at runtime.

The trade-off is coverage. Dynamic analysis only reveals behaviour that occurs during the observed session, on the tested device, under the tested conditions. If a feature is behind a user journey, feature flag, locale, or backend trigger that the test never reaches, the SBOM may still be incomplete. That is why dynamic analysis is not a replacement for static analysis, it is the runtime complement to it.

How both methods combine into a more trustworthy mobile SBOM

The practical difference is not which method is “better”, but which gap each one closes. Static analysis gives you the declared and embedded component view. Dynamic analysis gives you the observed and exercised component view. A mature mobile SBOM process reconciles both so teams can distinguish packaged-but-unused components from active runtime dependencies, and discover behaviour that affects privacy, attack surface, or downstream trust decisions. Open source supply chain guidance from OpenSSF is useful here because it reinforces the broader principle of inventorying what is actually present, not only what is claimed by the build.

For mobile applications, this combined approach is especially valuable when the app interacts with backend services, ad SDKs, analytics platforms, push notification services, or location-aware features. Those relationships may matter to SBOM consumers even when the package manifest looks clean. If you are also extending SBOM thinking into other software artefacts, NHIMG’s AI Supply Chain Security and AI-BOM Guide is a useful parallel because it explains how inventory, provenance, and runtime trust need to be considered together.

Risk and Threat Considerations

Mobile SBOMs become unreliable when teams rely on only one analysis mode. Static-only approaches can miss runtime-loaded libraries, hidden endpoints, and behaviour that appears only after authentication or feature activation. Dynamic-only approaches can miss dormant dependencies, compiled-in secrets, and packages that are present in the release artifact but not triggered during the test session.

Failure mechanism: An app can ship with dependencies that are invisible to one method, or activate network and code paths only under conditions that the test does not reproduce, creating a false sense of completeness.

Impact: The resulting SBOM may understate exposure, weaken vulnerability triage, and leave privacy, supply-chain, and endpoint-risk decisions based on partial evidence rather than the full mobile execution profile.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS, CIS Controls v8, NIST CSF 2.0 and OWASP SAMM set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP ASVS	V4 — API and Web Service	Mobile apps expose runtime API and service behaviour that SBOM work must capture.
Recommendation — Verify API and service dependencies as part of release review.
CIS Controls v8	CIS-15 — Service Provider Management	Mobile SBOMs often depend on third-party SDKs and services that need inventory and oversight.
Recommendation — Inventory third-party mobile dependencies and review them for trust and necessity.
NIST CSF 2.0	ID.AM-01 — Physical devices and systems are inventoried	SBOM generation is fundamentally an inventory problem for software components and observed dependencies.
	PR.DS-10 — Integrity is verified	Combining static and dynamic analysis helps verify the integrity of shipped mobile artifacts and runtime behaviour.
Recommendation — Maintain a current inventory of mobile components and runtime dependencies. Validate that shipped artifacts and runtime behaviour match expected integrity.
OWASP SAMM	DSR — Defect and Security Requirements	SBOM generation informs secure requirements and release decisions for mobile apps.
Recommendation — Define SBOM coverage requirements for both build-time and runtime analysis.

Practitioner Guidance

What to verify: Treat the SBOM as a reconciliation problem, not a single scan result. Verify that declared packages, embedded artifacts, runtime network destinations, and observed third-party services line up closely enough for your use case, and flag any meaningful mismatch for review.

What practitioners underestimate: The hardest misses are often conditional, such as code that only runs after login, only on a real device, or only when a feature flag is enabled. If your dynamic test matrix is narrow, assume the SBOM is incomplete until you have exercised the app across the conditions that matter.

Practitioner takeaway: Use static analysis for breadth and deterministic inventory, then use dynamic analysis to validate what the mobile app actually does in the field; SBOM quality depends on closing the gap between those two views.