Choose carefully. Tool choice in mobile app development brings enterprise risk

The mobile supply chain is more complex than we realise. Enterprise mobile apps combine proprietary code and open source, involving both first-party and third-party components. Pieces move across teams before being shipped as a simple download. Security tools are part of this chain. Teams integrate scanners, obfuscation, and runtime checks from different vendors, with each tool assessing only part of the app. This creates blind spots and potential conflicts.

This complexity is invisible to end users. It is not invisible to the enterprise that builds and ships the app. Every choice raises or lowers risk.

Mobile is now the primary business endpoint. Apps power work and growth by processing large volumes of sensitive data to deliver personal experiences. But the same access expands the enterprise attack surface.

Apps operate outside the enterprise perimeter. They reside on devices and networks you do not control. They contain code, keys, data, and expose APIs, all of which attackers value highly.

Too many tools, not enough protection

Enterprises develop apps for employees, partners, and customers. Risk now affects all three. Developer decisions influence that risk more than any policies do.

Most Android apps use free or basic security tools, according to our analysis, which estimates about sixty percent (60%). These tools help, but they fall short against modern attacks. 

App stores do not require the in-app protections most enterprises need today. Obfuscation, anti-tampering, strong runtime integrity, and strong key protection are not enforced. Passing the app store review does not guarantee that the app can withstand reverse engineering, malware, or device compromise.

Security tool fragmentation makes it more challenging. Teams must select tools that fit their stack and are compatible with multiple device models and OS versions. Integration becomes complicated as overlaps disrupt builds, protections degrade performance, and stability declines. Under pressure to deliver quickly, teams disable safeguards, leading to increased complexity and higher risk.

Security starts with visibility

You cannot protect what you cannot see.

Most teams scan code and run SCA on open source components. It is a great start but not enough for mobile apps. Many apps ship third-party SDKs as precompiled binaries. Well over sixty percent of top SDKs do this. SBOMs are partial or missing. Static scanners and SCA do not see inside those binaries. Teams also test an open-source version and then ship the compiled binary for speed. What actually runs on the device goes unchecked. Attackers are aware of this. Closed binaries effectively hide tampering. A poisoned SDK can pass through pipelines and reach millions of devices. Traditional scans and signature checks miss it. You need controls that assume parts of your supply chain are opaque.

Where the cracks appear

No, app hardening is common. Up to thirty-four percent (34%) of Android apps and sixty percent (60%) of iOS apps ship without code protection. This makes reverse engineering easier, leading to secrets and keys being exfiltrated and APIs being discovered by attackers.

Data leakage is also common. Forty-three percent (43%) of Android apps we analysed leak data, and up to sixty percent (60%) of iOS apps do as well. Weak TLS and poorly implemented SSL Pinning allow attackers to intercept or spoof traffic. Vulnerable encryption schemes further exposed data at rest and in transit.  

Most developers assume that mobile devices are secure and rely on their OS protections. However, more than half of devices operate on outdated OS versions at any given time. Many are already compromised. Without robust device and app integrity checks, an app cannot distinguish between safe and untrusted environments. 

The developer burden

Developers are not experts in mobile security. They require proper training and clear boundaries. Incentives prioritise speed, often causing security to be neglected until the end. Overlapping tools create confusion and conflicts. Builds are broken, and teams sometimes remove protections to keep the app stable. 

The outcome is predictable: insecure apps and a false sense of security.

What to prioritise now

You don't need a bunch of new or different tools. You need solutions that reduce the biggest risks and fit developer workflows. Here are three capabilities that are critical today. 

1. Code obfuscation

Make the app difficult to read when decompiled. Rename classes and methods, hide strings, and alter control flow so tools cannot easily reveal logic, keys, or API paths. Good obfuscation increases attack costs without impairing performance. A quick decompile should not reveal everything.

2. Anti tampering

Prove that the running app is the one you shipped. Verify signatures, package identity, and file integrity at launch and during use. Detect debuggers, hooks, and modifications to code or resources. If checks fail, block sensitive actions, limit features, and log the event so teams can respond.

3. Runtime visibility & protection

Assume that the device and network are untrusted. Detect root or jailbreak, emulators, overlays, keyloggers, unsafe Wi-Fi, and malware-related attacks. When risk is detected, hide sensitive screens, disable high-risk features, require step-up authentication, and prevent logins if needed. Bind API requests to a trusted app and device. Ideally, you should be able to update security without republishing the app. 

Bottom line

The mobile app security toolchain adds complexity and risk. The fix is not more tools. It is better education, clear guidance, and smarter choices. Pick the few controls that match today’s threats and fit how developers work. 

Build for resilience. What you ship is what you risk.