White House app testing shows why static analysis alone misleads

At a glance

What this is: NowSecure’s analysis shows that static analysis can flag capabilities in a mobile app that are not actually active at runtime.

Why it matters: For IAM, AppSec, and privacy teams, the distinction matters because app behavior, third-party SDKs, and OS permissions determine real exposure, not code presence alone.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read NowSecure's analysis of the White House app's static and dynamic testing results

Context

Mobile application risk is often overstated when teams treat code presence as proof of behaviour. In practice, static analysis identifies what an app can do, while dynamic testing shows what it actually does on a device. That distinction is especially important for high-profile apps where privacy claims, third-party SDKs, and platform permissions all shape the real security posture.

For identity and security teams, the issue is governance as much as testing. The app security lesson is that trust boundaries are enforced by runtime state, OS permissioning, and SDK configuration, not by code snippets alone. That makes the White House app a useful example of why AppSec, privacy, and mobile governance need both pre-release inspection and real-device validation.

Key questions

Q: How should teams verify whether a mobile app is actually collecting sensitive data?

A: Use both static and dynamic analysis. Static testing shows what code and dependencies are present, while dynamic testing confirms what the app does on a real device. Compare the observed network traffic, permission use, and runtime feature activation against the privacy claim before you treat any suspected behaviour as confirmed.

Q: Why do third-party SDKs create mobile security risk even when features are disabled?

A: SDKs expand the app’s potential capability set and can change behaviour across versions or configurations. Even disabled features matter because they reveal what the app could access if settings change, permissions are granted, or dependencies are updated. Governance should cover inventory, feature flags, and data-flow review, not just the app binary.

Q: What do mobile teams get wrong about app store review and platform controls?

A: They often assume baseline store checks are enough to validate real security or privacy behavior. In reality, app store review does not fully test runtime behaviour, third-party SDK activity, or real-world data flows. Platform controls still matter, but they must be verified through organisation-owned testing.

Q: How can security teams reduce false positives in mobile app risk reporting?

A: Require evidence from real-device testing before escalating claims about tracking, data collection, or covert functionality. Use clear criteria for when code presence becomes active risk, and separate speculative findings from observed behaviour. That keeps reporting accurate and avoids damaging trust with users, developers, and public stakeholders.

Technical breakdown

Static analysis vs dynamic testing in mobile AppSec

Static analysis examines the app binary, bundled libraries, permissions, and code paths to identify what could happen. Dynamic testing runs the app on a device or emulator and observes network calls, feature activation, and actual data flows. The two methods answer different questions. Static analysis is useful for finding dormant features or risky dependencies, but it cannot confirm whether a capability is enabled, reachable, or permitted by runtime controls. Dynamic testing closes that gap by validating behaviour under realistic operating conditions.

Practical implication: teams should treat static findings as hypotheses until runtime behaviour is verified on real devices.

Third-party SDKs and configurable capability risk

Modern apps often inherit functionality through SDKs such as analytics, messaging, or notifications packages. Those libraries may include optional features like location services, but optional does not mean active. Risk arises when teams fail to inventory which SDK capabilities are enabled, what data they can access, and how those settings change across versions. In mobile environments, the attack surface includes both the app code and the dependency graph that ships with it.

Practical implication: maintain an approved SDK inventory and review feature flags for every release, not just the app shell.

Why OS permissions still matter when code contains sensitive logic

Even if code references a sensitive capability, mobile operating systems still enforce permission boundaries before that capability can be used. On iOS and Android, location access, camera use, and other protected actions depend on explicit user or system approval. That means code presence alone does not bypass platform protections. Security teams should distinguish between implementable functionality, enabled functionality, and actually granted access, because each layer changes the real risk profile.

Practical implication: validate that privacy controls and OS permissions align with observed runtime behaviour before making exposure claims.

NHI Mgmt Group analysis

Static findings are not security findings until runtime validates them. The core governance error in this case is confusing capability with behaviour. That mistake is common in mobile security reporting and leads to overstatement or underreaction depending on what the code suggests. For AppSec teams, the lesson is to build evidence thresholds that require dynamic confirmation before privacy or exposure claims are accepted.

Third-party SDK governance is now part of mobile identity and privacy control. SDKs can introduce data collection paths, telemetry, and optional features that sit outside the core application design. When organisations do not manage those dependencies as part of the attack surface, they lose clarity on what data might flow, when it flows, and under whose control. That is a governance gap, not a scanning gap.

Runtime permissioning is the control boundary that matters most for sensitive mobile behaviour. Mobile operating systems still control access to location and other protected resources, so code references do not equal data access. This is where app governance intersects with identity and consent: a requested permission, a granted permission, and an active data flow are different states. Practitioners should treat those states as separate control checkpoints.

High-impact public-sector apps need a higher evidence bar, not a different security model. Government-facing mobile applications attract scrutiny, but the answer is not to infer worst-case behaviour from static code alone. It is to test more rigorously, document actual data flows, and simplify dependencies where possible. The named concept here is behaviour over capability drift: when teams assess potential instead of observed runtime, they create preventable credibility and governance failures.

Mobile privacy claims must be validated against observed behaviour, not intended design. That principle becomes more important as apps rely on configurable libraries and external services. If the stated privacy posture is not backed by runtime evidence, trust erodes quickly and remediation becomes harder. For security leaders, the practical conclusion is to require proof of observed data handling before asserting risk or compliance posture.

What this signals

Mobile AppSec programmes should treat runtime validation as a governance control, not a post-deployment debugging step. The practical shift is to align privacy assurance with observed behaviour, because code inspection alone cannot support credible claims about what an app actually does.

Behaviour over capability drift: when teams assess what a mobile app could do instead of what it does, they create avoidable reporting errors and weaken trust in security findings. That matters most where public visibility is high and third-party SDKs complicate the evidence trail.

For teams already using mobile testing pipelines, the next step is to join static findings to real-device evidence and documented permission states. That creates a cleaner control story for AppSec, privacy, and compliance stakeholders without overclaiming risk.

For practitioners

• Require dynamic validation before privacy claims are published Compare static findings with real-device network traces and confirm whether sensitive capabilities are enabled, invoked, and transmitting data. Use that evidence before approving public statements about tracking or collection behavior.
• Inventory SDK capabilities, not just SDK names Document which third-party libraries are present, which optional features are switched on, and which data paths those features can open. Review that inventory at each release because capability flags often change between versions.
• Separate requested, granted, and exercised permissions Track whether an app requests a protected permission, whether the user grants it, and whether the app actually exercises that access in runtime testing. Treat those as distinct checkpoints in mobile risk reviews.
• Build a release gate for mobile runtime testing Integrate static and dynamic analysis into CI/CD so every release is checked on real devices before deployment. Prioritise apps that handle sensitive personal data, support public services, or rely heavily on external SDKs.
• Simplify dependencies in high-scrutiny apps Reduce the number of external SDKs where possible and remove features that do not support a clearly documented business need. Fewer dependencies mean fewer hidden data flows and fewer configuration states to govern.

Key takeaways

• The main lesson is that code presence does not prove active data collection, especially in mobile apps with configurable SDKs.
• Runtime testing on real devices is the control that separates hypothetical capability from observed security behaviour.
• Security and privacy teams should govern SDK inventory, permissions, and release testing together rather than as isolated checks.

Key terms

• Dynamic Testing: Dynamic testing evaluates a mobile app while it is running on a real device or emulator. It shows actual network traffic, feature activation, and permission use, which makes it essential for confirming whether a capability discovered in code is truly active in production behaviour.
• Static Analysis: Static analysis inspects the app package, source code, or compiled binary without executing it. It is useful for identifying embedded libraries, permissions, and potential functionality, but it cannot prove whether those features are enabled or used at runtime.
• Third-Party SDK: A software development kit supplied by an external party and embedded into a mobile app to add functionality such as analytics, authentication, payments, or AI features. It can also introduce hidden data flows, permission requirements, and update risk that the owning team must actively govern.
• Runtime behaviour: Runtime behaviour is what an agent actually does after access has been granted, including tool use, data access, sequencing, and response to untrusted inputs. In agentic systems it is often the real security signal, because harm can occur without any authorization failure.

What's in the full article

NowSecure's full analysis covers the operational detail this post intentionally leaves for the source:

• Side-by-side static and dynamic test observations from the White House app analysis
• Runtime evidence that location data was not collected or transmitted on real devices
• Discussion of how OneSignal and similar SDKs can carry optional capabilities without those features being enabled
• Practical guidance on how high-impact apps should handle SDK review and mobile testing

👉 NowSecure's full post covers the runtime evidence, SDK context, and mobile testing implications in more detail.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. Explore it if your role includes access governance, secrets, workload identity, or broader identity risk management.