In March 2023, researchers at McAfee's Mobile Research team found a Kotlin-based advertising library called Goldoson embedded in 60 Android apps with a combined 100 million downloads on Google Play — quietly collecting installed app lists, Wi-Fi and Bluetooth device data, and clicking ads without user consent. The developers who shipped those apps never wrote a line of Goldoson's code; they just added a dependency. That gap between what a team builds and what actually ships is the essence of android third-party library risk: the average Android app pulls in dozens of external SDKs for ads, analytics, crash reporting, and payments, and each one inherits the same permissions, network access, and runtime privileges as the app itself. When one of those libraries misbehaves, gets compromised, or simply over-collects, the app — and its publisher — takes the blame. This post breaks down where that risk actually lives and what to do about it.
What is android third-party library risk, and why does every app carry it?
Android third-party library risk is the exposure an app inherits the moment it bundles an external SDK or open-source dependency, because that code runs inside the app's own process with the app's own permissions, network access, and storage — Android has no per-library sandbox. A typical consumer app today ships with somewhere between 15 and 30 third-party SDKs once you count ad networks, analytics, crash reporting, push notification, payment, and social-login libraries, according to repeated SDK-census research from firms like Lookout and AppFigures over the past several years. Each of those SDKs is a black box maintained by a separate company on its own release schedule, and each one can be updated — sometimes silently, via a remote config or server-side toggle — without the app developer reviewing a single line of new code. The app's privacy policy, App Store listing, and permission requests are written by one team; the actual runtime behavior is often decided by ten or more others.
How many permissions do third-party SDKs actually request?
Third-party SDKs routinely request permissions far beyond what their stated function requires, and ad and analytics libraries are the most common offenders. AppCensus's long-running analysis of Android ad SDKs has repeatedly found libraries reading ACCESS_FINE_LOCATION, READ_PHONE_STATE, and the Android Advertising ID together in ways that let a single SDK vendor build a persistent device fingerprint across every app that embeds it — not just the one app the user is currently looking at. Because Android's permission model is granted at the app level, a user who allows a flashlight app to use location "to show nearby weather" is often actually granting that permission to three or four embedded ad SDKs simultaneously. The developer sees one permission prompt; the SDK vendors see a location feed. This is also why permission audits that stop at "what does our app request" miss the real question: what does each embedded library do with the permission once it's granted.
What does the android SDK supply chain actually look like?
The android SDK supply chain is a multi-tier system of Maven Central, Google's Maven repository, JitPack, and private CDNs, and a single line in build.gradle can pull in a tree of transitive dependencies nobody on the team has ever inspected. Adding one ad network SDK frequently drags in five to ten additional libraries for networking, JSON parsing, and analytics that the ad network itself depends on — and Gradle resolves those transitively by default. This chain has a long memory: Check Point's 2023 "Dirty Stream" and related research found that the Play Core Library vulnerability tracked as CVE-2020-8913, which allows local code execution via a malicious app exploiting another app's file provider, was still present and unpatched in a meaningful share of top-downloaded Google Play apps years after a fix was published, because the vulnerable library was buried several dependency layers deep and never flagged for update. Nobody re-audits a dependency that "already shipped and works."
How does kotlin dependency security differ from the Java-era risks?
Kotlin dependency security introduces new failure modes on top of the old Java/Gradle ones, mainly because Kotlin projects lean even harder on dynamic version ranges, Kotlin Multiplatform (KMP) artifacts, and community package hosts like JitPack that mirror GitHub repos directly into build artifacts. A build.gradle.kts file that pins a dependency to 1.+ or latest.release will silently pull a new — and potentially compromised or typosquatted — version on every clean build, with no lockfile forcing a human to notice the change. JitPack in particular builds straight from a GitHub tag at request time, which means the trust boundary is "whatever is in that repo right now," not a reviewed, immutable release artifact. Combine that with Kotlin's growing use for shared business logic across Android and iOS via KMP, and a single poisoned Kotlin library can now cross both platforms' supply chains at once, something that wasn't possible when Android and iOS codebases were fully separate Java and Objective-C/Swift trees.
Can a single mobile library data leak affect hundreds of apps at once?
Yes — a mobile library data leak in one shared SDK routinely fans out to every app that embeds it, and the scale can be enormous. In May 2023, security firm Dr.Web disclosed that a game-marketing SDK called SpinOK was bundled in 193 Android apps on Google Play with a combined 421 million installs, and was quietly harvesting clipboard contents, files, and device data while presenting itself as a rewarded-ads module. Earlier, in 2017, Lookout researchers found the Igexin ad SDK embedded in apps with roughly 100 million cumulative downloads, some of which received server-side instructions to download additional executable code post-install — turning a routine ad library update into a remote code delivery channel. And in 2023, Oversecured's research into a widely used mobile cloud SDK found hardcoded cloud storage credentials shared across thousands of client apps, meaning a flaw in one vendor's SDK exposed backend storage buckets for every app that had integrated it, regardless of how carefully each individual app team had built their own code.
How Safeguard Helps
Safeguard treats every Android build the way this problem actually behaves: as a supply chain, not a single codebase. Rather than asking a mobile team to manually track what each embedded SDK does, Safeguard generates a continuous software bill of materials (SBOM) for Android and Kotlin projects that resolves the full Gradle dependency tree — direct and transitive — and flags version ranges, unpinned JitPack coordinates, and known-vulnerable library versions such as outdated Play Core builds before they ship.
Beyond static inventory, Safeguard correlates each SDK against known incident and CVE data, so a library implicated in a prior data-leak disclosure or a typosquat campaign gets surfaced immediately rather than discovered after a security researcher's blog post. For teams shipping Kotlin and Kotlin Multiplatform code, Safeguard's dependency analysis extends across both the Android and iOS build outputs, since a single shared library can affect both platforms simultaneously. And because SDK behavior can change after release through server-side updates, Safeguard supports policy gates in CI/CD that block a build when a monitored dependency's declared permissions, network endpoints, or version pin drift outside of an approved baseline — catching the silent update before it reaches production, not after it's already collecting data from millions of installs.
The goal isn't to eliminate third-party libraries — modern apps can't ship without them — it's to make sure every one of them is visible, versioned, and accountable before it runs on a user's device.
