SAN FRANCISCO — July 2026 — Mobile applications now ship with more third-party code than first-party code, and that ratio keeps climbing. Across the app security telemetry Safeguard's research team tracks alongside public advisory feeds (NVD, GitHub Security Advisories, OSV), the story of the past eighteen months is consistent: the average consumer mobile app pulls in 30 to 50 external SDKs and open-source packages, and a growing share of newly disclosed vulnerabilities in mobile ecosystems trace back to transitive dependencies — libraries the app team never directly chose, buried three or four levels deep in a dependency tree. Mobile is repeating, almost beat for beat, the supply-chain reckoning that hit server-side JavaScript and Python ecosystems in 2021–2023. The difference is that mobile's release cadence, app-store review lag, and binary distribution model make remediation slower and detection harder.
This report walks through what the current data says about mobile dependency risk, where the fault lines are concentrated by platform and package manager, why conventional software composition analysis (SCA) tooling underperforms on mobile artifacts, and what security and engineering teams can do to close the gap.
The Expanding Attack Surface
Three structural shifts are driving the increase in mobile dependency exposure:
- Cross-platform frameworks widened the blast radius. React Native, Flutter, and Cordova/Capacitor apps inherit not just native mobile package risk but the entire npm and pub.dev dependency graph as well. A single React Native app can realistically depend on 800–1,500 npm packages once transitive dependencies are counted, compared to the dozens of native SDKs a purely native app might carry.
- Ad tech, analytics, and monetization SDKs multiplied. Monetization pressure has pushed the median app to integrate multiple advertising, attribution, crash-reporting, and analytics SDKs — each with its own dependency chain, update cadence, and in some cases, its own embedded native libraries and permissions requests.
- Build-time dependency resolution obscures what actually ships. CocoaPods, Swift Package Manager, and Gradle all resolve version ranges at build time, meaning the exact vulnerable version that lands in a shipped
.ipaor.apkcan differ from what's pinned in source control — and frequently isn't captured anywhere for later audit.
The net effect: most mobile AppSec programs can tell you what's in their Podfile or build.gradle, but far fewer can tell you, with confidence, what shipped in last quarter's binary — let alone whether any of it is reachable and exploitable at runtime.
What the Trend Data Shows
A few patterns stand out when looking at disclosure volume and remediation behavior across mobile-relevant ecosystems over the last few release cycles:
- Disclosure volume is rising fastest in JavaScript-adjacent mobile tooling. npm-sourced advisories affecting React Native, Expo, and Cordova plugin ecosystems have grown at a noticeably faster rate than native Android (Maven Central) or iOS (CocoaPods/SPM) advisories over the same window — consistent with npm's broader position as the largest and most frequently-flagged open-source registry industry-wide.
- Time-to-patch is longer on mobile than on web or backend services. Because a fix requires a new build, a store review cycle, and — critically — active user adoption of the update, the effective window during which a vulnerable dependency remains exploitable in the wild after a patch is published is measurably longer for mobile than for server-side software, where a fix can ship the same day.
- Abandoned and low-maintenance SDKs are an outsized share of risk. A disproportionate number of newly-flagged mobile dependency issues land in SDKs with irregular maintenance — advertising and utility libraries that were integrated years ago, never revisited, and now sit several major versions behind with known, unpatched CVEs.
- Permission-adjacent libraries draw the most severe findings. Dependencies that request location, contacts, device identifiers, or storage access carry a disproportionate share of high/critical severity findings, both because vulnerable code in these libraries has a larger practical impact and because they're attractive targets for supply-chain compromise (a malicious update to a widely-embedded SDK can reach millions of devices at once, echoing the dynamics seen in prior ad-SDK and analytics-SDK compromise incidents across the industry).
Platform-Specific Fault Lines
Android / Gradle & Maven. Android's dependency graph is deep and often includes multiple versions of the same underlying library pulled in transitively by different SDKs — a known contributor to "dependency confusion" style conflicts and to vulnerable versions surviving in the final APK even after the top-level dependency was bumped.
iOS / CocoaPods & Swift Package Manager. CocoaPods' historical trust model (source-based specs, looser integrity verification than lockfile-based ecosystems) has made it a repeated subject of supply-chain research. SPM's growing adoption is an improvement on reproducibility, but many long-lived apps still run a mixed CocoaPods/SPM dependency tree, complicating a clean SBOM.
Cross-platform / npm. React Native and Cordova/Capacitor apps inherit npm's well-documented supply-chain risk profile — typosquatting, maintainer account takeover, and post-install script abuse — but now with the added twist that a compromised package can also touch native device APIs through bridge modules, not just JavaScript execution context.
Why Traditional SCA Falls Short for Mobile
Most SCA tooling was built for server-side manifests — package.json, requirements.txt, pom.xml — where the dependency graph and the running artifact are close to the same thing. Mobile breaks that assumption in three ways:
- Manifest-to-binary drift. What's declared in
Podfile.lockorbuild.gradleisn't always what ends up in the shipped binary, especially with dynamic version ranges, flavors, and build variants. - No visibility into reachability. A flagged CVE in a bundled library may sit in a code path the app never calls. Flat CVE-count dashboards drive teams to burn cycles patching dependencies that pose no real exploitability risk, while genuinely reachable, high-impact issues get lost in the noise.
- Fragmented ownership. Mobile dependency risk is split across app engineering, platform teams, and third-party SDK vendors, with no single system of record. Most organizations still can't produce an accurate SBOM for a shipped mobile binary on demand — a gap that increasingly collides with SBOM expectations from enterprise customers, regulators, and app-store policy requirements.
What Security Teams Should Do Now
Given these dynamics, a mobile-aware dependency risk program should:
- Generate SBOMs from the actual built artifact (APK/IPA), not just the source manifest, to capture what truly ships.
- Prioritize findings by reachability and exploitability, not raw CVE count, given how much dependency code in mobile apps is never invoked at runtime.
- Track SDK maintenance health (release cadence, unresolved advisories, maintainer activity) as a leading indicator, not just point-in-time CVE matches.
- Build a fix pipeline that assumes longer patch propagation windows than server-side software, with compensating controls (WAF-equivalent mitigations, feature flags, forced-update prompts) for the gap between patch availability and user adoption.
How Safeguard Helps
Safeguard is built to close exactly this gap between what a mobile app declares and what it actually ships and executes. Safeguard ingests or generates SBOMs directly from built mobile artifacts and dependency manifests across npm, CocoaPods, SPM, Gradle, and Maven, giving teams a single accurate inventory instead of a source-only approximation. From there, Safeguard's reachability analysis determines which vulnerable dependencies — including deeply transitive ones — sit on code paths the app actually calls, cutting through CVE-count noise to surface the findings that carry real exploitability risk. Griffin AI, Safeguard's security reasoning engine, correlates that reachability data with SDK maintenance signals and exploit context to triage and explain findings in plain language for engineering teams unfamiliar with a given library's history. Where a fix is available, Safeguard opens auto-fix pull requests that bump the vulnerable dependency to a patched version validated against the existing test suite, shrinking the time-to-patch window that mobile release cycles otherwise stretch out. Together, these capabilities let security and mobile engineering teams manage dependency risk as an ongoing, reachability-informed practice rather than a pre-release scramble.