A critical vulnerability lands in a library you use. On the server you patch it, deploy, and by lunchtime nothing vulnerable is running.
In a mobile app you patch it, submit a release, wait for review, and then wait for users to update. Weeks later a meaningful share of your install base is still running the vulnerable version, and some of them will still be running it next year. You cannot force the fix, and you cannot make the old version stop working unless you built that ability in advance.
This post is about that difference and what follows from it. For whoever owns a mobile app that bundles third-party SDKs, which is every mobile app.
The adoption curve is the real problem
Server-side remediation is a deployment. Mobile remediation is a distribution problem with a long tail you do not control.
Typical shape after a release: a large fraction of users update within the first week or two, most of the rest over the following month, and then a stubborn remainder that persists indefinitely. Devices that no longer receive OS updates, users with automatic updates disabled, enterprise-managed fleets on a controlled release cycle, regions with expensive data.
So "we fixed it" means something different. The honest statement is that the fix is available, adoption is at some percentage, and the remaining share is still exposed. If you cannot state that percentage, you do not know your exposure.
Measure it. Your analytics or crash reporting already reports app version. Build the chart once, and it will change how you talk about mobile vulnerabilities.
What the SDKs actually have
An SDK bundled in your app is not a dependency in the server sense. It runs inside your process, with your app's permissions, and every permission your app has been granted it has too: camera, location, contacts, the keychain entries your app can read, the network with your app's certificate trust.
The categories that accumulate: analytics, crash reporting, advertising and attribution, authentication, push notifications, chat and support widgets, payment, and feature flag tooling. Each was added for a good reason by someone who needed one capability.
Two consequences worth stating plainly.
A compromised SDK is a compromised app, with full access to whatever the user granted you. There is no sandbox between your code and the SDK's.
The SDK's data collection is your data collection. You declare it in your app store privacy disclosures, you answer for it under GDPR, and it goes on your subprocessor list. Several SDKs collect considerably more than their documentation implies, and the accountability is yours regardless.
Build the ability to respond before you need it
The controls that matter are the ones that have to exist in advance, because after the advisory it is too late.
A remote kill switch per SDK. A feature flag that disables an SDK's initialisation without a release. When a vulnerability lands in an analytics SDK, you can turn it off in the deployed app within minutes and lose analytics until you ship a fix. This is the single highest-value thing on this list and it must be built before it is needed.
A forced upgrade mechanism. The app checks a minimum supported version at launch and blocks with an update prompt below it. Hostile to users, so reserve it for real severity, and it is the only way to actually end the tail.
Server-side enforcement. Your API can refuse or degrade requests from app versions below a threshold. This works even if the client-side check is bypassed, and it is the version that holds against an attacker rather than an ordinary user.
Keep sensitive operations server-side. The general defence. If the secret is not in the app and the decision is not made in the app, a compromised SDK has less to take.
Inventory and reduce
Enumerate what ships. Not the manifest, the artifact. Inspect the built app and list what is actually inside, including transitive SDKs that arrived as dependencies of the ones you chose. The list is usually longer than the team expects.
For each one: what does it do, what data does it collect, who owns it, when was it last updated, could we remove it. The last column is the productive one. Mobile SDKs accumulate because removal requires someone to decide the capability is no longer needed, and nobody is assigned that decision.
Pin versions. An SDK resolved by a version range means your next build may include code nobody reviewed.
Watch for ownership changes. An SDK sold to a new owner, or an analytics vendor acquired by an advertising company, changes what the code does without changing its name. This has happened repeatedly and it is invisible unless someone is watching.
Practical checks
# Android: what is actually in the APK
unzip -l app-release.apk | grep -E '\.(so|dex)$'
./gradlew app:dependencies --configuration releaseRuntimeClasspath | head -60
# iOS: frameworks embedded in the bundle
ls -1 YourApp.app/Frameworks/
otool -L YourApp.app/YourApp | head -40
Then compare against your declared privacy disclosures. A framework in the bundle that is absent from your data disclosure is a compliance finding as well as a security one.
The concession
Much of this argues for fewer SDKs, and that has a genuine cost. Writing your own crash reporting, analytics or authentication is expensive, worse than the vendor's, and a poor use of a small team. The vendors exist because building this yourself is a bad trade.
So the position is not minimalism for its own sake. It is that each SDK should be attributable to a capability someone would miss, reviewed for what it collects, and paired with a kill switch. Three SDKs nobody can justify is the finding, not the fact of using SDKs.
The implication
The mobile difference is not that the risks are exotic. It is that your remediation is slow, partial, and permanently incomplete, which changes what a vulnerability costs you.
That argues for spending less effort on scanning and more on the two things that shorten the response: a kill switch per SDK, and an enforcement point on the server that does not depend on users updating anything.
