Mobile app privacy scanning: finding undisclosed SDKs and trackers
What it is
OneTrust's app scanner analyzes a mobile app binary or build artifact to automatically discover which third-party SDKs it includes, what data those SDKs are capable of accessing, and cross-references that against what's actually declared in App Store Privacy Nutrition Labels and Google Play Data Safety sections. It's functionally the mobile equivalent of the web cookie and tag discovery covered on this site's own vendor-discovery use case - built for the fact that mobile SDKs get added transitively through dependencies just as often as web scripts get added by a marketing tool nobody told engineering about.
When you need it
Your team needs to keep App Store and Play Store privacy declarations accurate as SDKs get added or updated between formal reviews - a stale label is its own app-store policy risk, separate from any privacy-regulation exposure.
Privacy doesn't have direct visibility into what mobile engineering has actually integrated, especially SDKs pulled in as a dependency of a dependency rather than added deliberately.
You're doing a pre-submission or pre-major-release compliance pass and want a discovered inventory to check against, not just engineering's own recollection of what's in the build.
How to implement it
- 1
Submit the binary or connect the scanner to your build pipeline
Which build formats and CI integrations are supported is specific to your OneTrust configuration - verify against current OneTrust docs for the exact supported integration point before assuming a given format works.
- 2
Review the discovered SDK inventory against engineering's own understanding
Undeclared or transitively-included SDKs are exactly what this catches - treat a mismatch between the scan and engineering's mental model as the expected finding, not a scanner error.
- 3
Cross-reference findings against current App Store and Play Store declarations
Correct any mismatch before your next submission, not after a rejection - a scan that surfaces an undeclared data type is only useful if it's acted on before the store review catches it.
- 4
Run the scan on a recurring basis or as a build-pipeline gate
SDKs get added or updated between formal privacy reviews, so a one-time audit goes stale the moment the next dependency update ships.
- 5
Route newly discovered SDKs into the same vendor-risk review as web vendors
This site's vendor-list-under-control use case covers the web-side version of that workflow - mobile and web vendor governance shouldn't live in two disconnected processes just because the discovery tooling is different.
How to verify it worked
After a scan, manually check at least one SDK integration you know is in the codebase against the scan's inventory to confirm it was correctly detected, rather than trusting a summary count alone.
Deliberately add a test SDK dependency, re-run the scan, and confirm it appears in the next report.
Compare your current App Store and Play Store privacy labels against the scan's findings and confirm there's no data type in the scan left undeclared in either store listing.
Related
Want this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.