NowSecure's 2026 Mobile App Risk Management Survey found that 68% of organizations report having more than half their mobile codebase built from third-party SDKs. For most teams, the majority of what ships in their app is code they didn't write, and mobile app security testing hasn't caught up to that shift.
Share of mobile codebase built from third-party SDKs
Assessment practices haven't kept pace with the shift. Only 49% of organizations say they always assess third-party SDKs before release. Roughly half are shipping the majority of their own codebase without a consistent review before it reaches users.
The Assessment Gap
This isn't a knowledge problem. Most security teams know their apps depend on external SDKs for analytics, payments, crash reporting and a dozen other functions. The report's own framing draws the line precisely: identifying components differs from understanding their behavior. Knowing an SDK is present in a build tells you what's included. It doesn't tell you what that SDK does once the app is running, what data it accesses or what changes with each update.
The survey data suggests most organizations have gotten reasonably good at the first question and stayed inconsistent on the second, which is really the question in the headline: is that third-party majority of your codebase getting tested like it's yours, or treated differently because it isn't?
What the Incident Data Shows
Incident rates rise as testing coverage narrows. Organizations that test all of their apps report a 48% incident rate. Among organizations that test only most of their apps, that climbs to 77%. Among organizations that test only some, it reaches 96%. Testing coverage and third-party SDK assessment measure the same underlying discipline from two angles, and the survey shows what happens as either one narrows.
A newer dependency layer sits on top of this pattern. 45% of organizations report using third-party AI SDKs in their mobile apps, a category that's less mature and less well understood than the traditional SDK ecosystem most teams have spent years learning to manage. Assessment practices built around analytics and payment SDKs don't automatically extend to it, and the survey data doesn't show organizations treating AI SDKs as a distinct risk tier yet.
What to Do Differently
Closing this gap means extending a discipline most teams already run, to the code they didn't write themselves:
- Inventory every third-party SDK in the build, including nested and transitive dependencies, so the count reflects what's actually shipping.
- Apply pre-release SDK assessment as a standard across every app, so coverage doesn't quietly concentrate on flagship releases.
- Give third-party AI SDKs their own review category, separate from general SDK assessment, given how differently they behave.
- Reassess SDKs on each update, since behavior can shift between versions even when the SDK itself hasn't been swapped out.
- Track testing coverage as its own metric, since the survey links incomplete coverage to higher incident rates.
Mobile apps remain one of the least consistently tested parts of the software stack, and third-party code is now most of what's in them. That gap closes when pre-release SDK assessment gets treated as a release gate rather than an occasional check, and when the same scrutiny is extended specifically to third-party AI SDKs rather than folded into a general SDK review.
That last point connects to a broader pattern in this survey. Most organizations report having some form of AI governance policy in place, but a policy written before third-party AI SDKs became common in the ecosystem may not actually account for that dependency layer. The two findings point at the same underlying issue from different angles: organizations are building the right frameworks, but the frameworks and the testing practices underneath them haven't caught up to where the code is actually coming from.
"Identifying components differs from understanding their behavior."
