In September 2023, Apple shipped iOS 16.6.1 as an emergency patch for CVE-2023-41064 and CVE-2023-41061 — the two-bug chain known as BLASTPASS that NSO Group's Pegasus spyware used to compromise iPhones with zero clicks. No tap, no link, no warning — just a malicious PassKit attachment delivered through iMessage. That single chain is a useful reminder that mobile application security isn't web security with a smaller screen; it's a distinct attack surface with its own OS sandboxing model, app store review gates, compiled binaries, and offline data storage risks. Google's 2023 Play Store safety report says it removed 2.28 million policy-violating apps that year, and the 2024 revision of the OWASP Mobile Top 10 added an entirely new category — Inadequate Supply Chain Security — because so many mobile incidents now start in a bundled SDK rather than in code a developer wrote. This post walks through the concrete risks and the mobile security tools that address them.
What Is Mobile Application Security?
Mobile application security (MAS) is the practice of protecting iOS and Android apps — and the backend APIs, third-party SDKs, and on-device data stores they depend on — across the full lifecycle from source code to app store distribution to runtime on a device you don't control. That last part is what makes mobile different from web AppSec: a mobile app ships as a compiled binary (an IPA or APK) that runs on hardware, OS versions, and jailbroken/rooted environments the vendor can't standardize, so testing has to cover static code, the compiled artifact, and live runtime behavior. The industry benchmark is the OWASP Mobile Application Security Verification Standard (MASVS), paired with the OWASP Mobile Top 10, last substantially revised in 2024 to reflect how much mobile risk now originates outside the app's own codebase. Most mature programs run mobile-specific static analysis (MAST) in CI, dynamic instrumentation against pre-release builds, and binary-level checks before every app store submission.
What Are the Most Common Mobile App Security Risks?
The most common risks, per the 2024 OWASP Mobile Top 10, are improper credential usage (M1), inadequate supply chain security (M2), and insecure data storage (M9) — in that order of prevalence in real audits. Improper credential usage means API keys, OAuth secrets, or signing keys hardcoded into the binary; a 2022 CloudSEK study scanning public app stores found thousands of Android and iOS apps leaking live AWS access keys directly in decompiled code, some with write access to production S3 buckets. Insecure data storage shows up as unencrypted SQLite databases, plist files, or shared preferences holding session tokens or PII in plaintext on the device, retrievable by anyone with physical access or a basic backup-extraction tool. And CVE-2019-13450, the Zoom iOS vulnerability disclosed by researcher Jonathan Leitschuh, showed a fourth pattern: the app silently ran a local web server on the device to bypass Apple's permission prompts, which any malicious website could then call to activate the camera without consent — patched only after public disclosure forced Zoom's hand within 24 hours.
How Does Mobile Supply Chain Risk Differ From Web Supply Chain Risk?
Mobile supply chain risk differs because the vulnerable code is compiled into a single binary at build time, so there's no package.json or requirements.txt to inspect after the fact — you have to catch the SDK before it's baked into the app or reverse-engineer the artifact after release. A typical consumer app bundles a dozen or more third-party SDKs for ads, analytics, crash reporting, and payments, each with its own update cadence and its own access to device permissions, and each invisible to standard web-style dependency scanners. The clearest historical example is XcodeGhost in 2015: attackers distributed a trojanized copy of Apple's Xcode IDE through Chinese file-sharing sites, and any developer who compiled with it unknowingly injected malware into their app — infecting more than 4,000 iOS apps, including WeChat, and an estimated 100 million-plus devices, without a single line of malicious code written by the affected developers. That's exactly the failure mode OWASP's 2024 M2 category was added to cover, and it's why SBOM generation for mobile artifacts — not just server-side services — has become a baseline requirement rather than a nice-to-have.
What Tools Are Used for Mobile Application Security Testing?
Teams combine mobile-specific static/dynamic analysis (MAST), binary and SBOM tooling, and the platform vendors' own review gates rather than relying on a single scanner — no one set of mobile security tools covers the whole lifecycle on its own. MobSF (Mobile Security Framework) is the widely used open-source baseline for static and dynamic analysis of APKs and IPAs; Frida and Objection are the standard tools for runtime instrumentation — hooking into a running app to bypass certificate pinning or dump memory during a pentest. Commercial SAST/DAST platforms (Checkmarx, Veracode, Snyk Code) have added mobile-language support for Swift, Kotlin, and Java, while RASP vendors like Guardsquare and Zimperium focus on binary hardening and in-app threat detection for production builds. On the distribution side, Google Play Protect scans apps continuously across the Play ecosystem, and Apple's App Review rejected or removed roughly 1.7 million app submissions in 2022 for policy and privacy violations — both useful backstops, but neither is a substitute for testing before submission, since app store review catches policy violations, not exploitable logic flaws.
How Should Teams Prioritize Mobile Vulnerabilities?
Teams should prioritize by reachability and exploitability, not by raw finding count, because a single mobile SAST scan against an app bundling a dozen SDKs routinely returns hundreds of findings and no security team ships a fix for all of them before the next release. A hardcoded secret sitting in an analytics SDK's dead code path that the app never actually calls is a materially different risk than the same class of finding wired directly into the login flow — but both show up identically in a flat vulnerability list unless something maps the finding to actual code execution. This is the same lesson web AppSec learned with dependency scanning: a CVE in a transitive dependency you never invoke doesn't deserve the same 24-hour SLA as one sitting in a function your app calls on every request. Mobile teams need that same reachability lens applied to compiled binaries and bundled SDKs, not just to source-level package managers.
How Safeguard Helps
Safeguard applies reachability analysis to mobile codebases and their bundled SDKs, so a finding in a third-party library only gets escalated when Safeguard can trace an actual call path from your app's code into the vulnerable function — cutting through the hundreds of theoretical findings a raw mobile SAST scan produces. Griffin, Safeguard's AI triage engine, reviews each reachable finding in context, explains the exploit path in plain language, and drafts an auto-fix pull request your team can review and merge instead of hand-patching a decompiled dependency. Safeguard also generates SBOMs directly from iOS and Android build artifacts — not just from source manifests — and ingests SBOMs from your existing CI pipeline, so bundled SDKs that never touch a package.json still show up in your inventory. For teams juggling mobile, web, and cloud-native supply chains at once, that means one reachability-driven pipeline instead of a disconnected mobile scanner bolted onto a web-focused AppSec program.