White House app testing shows why static analysis alone misleads

At a glance

What this is: NowSecure tested the White House mobile app and found that static analysis had overstated the privacy risk because real-device testing did not show unauthorized location tracking.

Why it matters: AppSec and DevSecOps teams need both static and dynamic testing because code presence, SDK capability, and actual runtime behaviour are not the same thing.

Context

Static analysis answers what code and configuration are present in a mobile app, but it cannot prove whether a capability is actually exercised at runtime. That distinction matters for appSec, privacy review, and third-party SDK governance because false positives can distort risk prioritisation and distract from observable behaviour.

The White House app case is a good example of why mobile security decisions should not rely on code inspection alone. When an app uses third-party components and platform permissions, practitioners need evidence from real-device testing before concluding that location collection, data transmission, or other sensitive behaviour is taking place.

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 can static analysis overstate privacy risk in mobile apps?

A: Static analysis shows what code is present, not what the app executes. SDKs often include optional features that are disabled, gated by permissions, or unused in production. Without runtime testing, teams can mistake dormant capability for live data collection and escalate a finding that does not reflect actual behaviour.

Q: What are the signs that a third-party SDK is creating mobile privacy risk?

A: Look for enabled data collection, unexpected network calls, excessive permissions, and features that activate only after configuration changes or user consent. The SDK itself is not the problem. The risk appears when its runtime behaviour expands the app’s data flows beyond what the business actually needs.

Q: Should organisations rely on app store review to catch mobile app security issues?

A: No. App store review is a baseline gate, not a full runtime assurance process. It can miss third-party SDK activity, data flows that only appear on real devices, and configuration-dependent behaviour. Organisations with high-impact apps need independent testing to validate both security controls and privacy claims.

Technical breakdown

Why static analysis overstates mobile app behaviour

Static analysis inspects source code, binaries, permissions, and embedded libraries to infer what an app could do. That is useful for finding exposed capabilities, but it cannot confirm whether code paths are reachable, features are enabled, or data is actually transmitted. In modern mobile apps, SDKs often ship with broad optional features that developers selectively activate. Without runtime observation, teams can confuse dormant capability with live behaviour and overstate privacy risk.

Practical implication: Treat static analysis as a control for discovery, not proof of execution, and require runtime validation before escalating a privacy finding.

How dynamic testing validates third-party SDK risk

Dynamic testing runs the app on a real device or emulator and observes network traffic, sensor use, permission requests, and feature activation. That is the only practical way to confirm whether a third-party SDK is collecting data, calling remote services, or respecting platform permissions. For privacy-sensitive apps, this closes the gap between embedded code and real-world behaviour. It also shows whether a dependency is enabled by default or only becomes active after a user grant or configuration change.

Practical implication: Test high-impact apps on real devices so third-party SDK claims are verified against observable network and permission behaviour.

Why platform permissions still matter even when code exists

Mobile operating systems mediate access to sensitive data such as location, contacts, and sensors. A library may contain location-related code, but that code still cannot bypass the OS permission model without user consent and a valid runtime path. This is why code presence alone is a weak indicator of surveillance or exfiltration. AppSec teams need to separate permission exposure from permission use, especially when reviewing privacy claims, app store disclosures, and third-party component inventories.

Practical implication: Map sensitive features to both permission settings and observed runtime activity before concluding that a mobile app can access protected data.

NHI Mgmt Group analysis

Static analysis creates a capability illusion: code inspection is valuable for finding what a mobile app could do, but it routinely overstates risk when teams treat dormant features as active behaviour. The White House app coverage shows how quickly a permission flag or SDK capability can be mistaken for actual data collection. For practitioners, the governance problem is not code visibility itself, but the false certainty that comes from stopping there.

Dynamic testing is the missing control plane for mobile privacy assurance: runtime observation is what distinguishes an enabled collection path from an unused library function. In mobile app programmes, that means privacy review, AppSec, and DevSecOps all need the same evidence standard before a finding becomes an incident. For teams governing high-impact apps, behaviour is the control boundary that matters.

Third-party SDKs expand the review surface even when they are not active: libraries like notification and analytics components often bundle optional capabilities that complicate risk assessment. That does not make every embedded SDK a privacy event, but it does make dependency governance part of mobile identity and trust management because external code can alter what the app is permitted to do. For practitioners, SDK inventory without runtime verification is incomplete assurance.

High-impact mobile apps need verification discipline, not headline discipline: government, finance, healthcare, and large consumer apps attract scrutiny precisely because their risk narratives spread faster than their evidence. The more sensitive the app, the more important it is to prove behaviour against actual device telemetry and platform controls. For security leaders, the lesson is to anchor mobile app governance in observed data flows, not inferred possibilities.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Runtime evidence should outrank inferred capability in mobile governance: appSec teams that stop at static inspection will continue to misclassify dormant code as active risk. The practical shift is to make real-device telemetry the point at which a privacy or security claim becomes actionable.

SDK governance is now a verification problem, not just an inventory problem: third-party components can bundle features that matter only when they are enabled, permitted, and observed. That means dependency review, permission review, and traffic review have to be linked in the same workflow.

The White House app example also reinforces a broader programme lesson: the quality of a mobile security decision is only as good as the evidence behind it. When runtime behaviour is missing, conclusions about user tracking and data collection become speculative rather than defensible.

For practitioners

• Run static and dynamic testing together Use static analysis to find embedded code and dynamic testing to confirm what the app actually transmits or activates on real devices.
• Review every third-party SDK as part of the attack surface Inventory notification, analytics, messaging, and similar components, then verify whether each dependency is enabled, collecting data, or relying on remote services.
• Validate privacy claims against observed behaviour Compare app store disclosures, internal privacy statements, and runtime network traces so claims about location or other sensitive data match actual flows.
• Preserve platform security controls Keep transport protections, OS permissions, and encryption defaults intact instead of disabling them globally to simplify testing or integration.

Key takeaways

• Static analysis can reveal embedded capabilities, but it cannot prove that a mobile app is using them in practice.
• The White House app example shows why runtime testing is essential before concluding that a third-party SDK is collecting sensitive data.
• Mobile app risk management should combine code review, device-level validation, and privacy claim verification so behaviour, not speculation, drives decisions.

Key terms

• Static analysis: Static analysis is the inspection of source code or configuration without executing it. It helps identify insecure patterns early, but its value depends on accuracy, timing, and whether the output is usable enough for developers to fix issues while they are still working on the code.
• 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.
• 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.

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 course is designed for practitioners who need a stronger governance baseline across identity, privilege, and lifecycle control.