List every SDK and transitive library in the build, record what each one collects and where it sends data, check its terms against how your app is used, decide to keep, configure, replace, or remove, and repeat on a schedule. Start from lockfiles and build output, not from memory.
Why mobile apps need their own audit
A mobile app bundles its dependencies into one binary that ships to student devices. You cannot patch it on the server. A bad SDK stays on devices until users update. And app stores apply their own rules: Google Play's Families policy, for example, says apps aimed at children must not contain SDKs that are not approved for primarily child-directed services, and that developers must disclose child data collection through the SDKs they use.
Step 1: Build the inventory
Pull the resolved dependency list from your build tooling for each platform. For Android that means your Gradle dependency report. For iOS it means your package resolution file or pod lock file. Include transitive packages, because they ship too.
Record name, version, license, and purpose. If nobody on the team can say why a package is there, mark it for removal review.
Step 2: Map the data flows
For each SDK, answer three questions:
- What data does it read? Identifiers, location, contacts, files.
- Where does it send data? Which domains.
- Can it be turned off by configuration?
You can check network behavior by running the app in a test environment with a proxy and noting every outbound domain during normal use. Compare the list with what you expected.
Step 3: Read the terms
The Google Play policy lists a common violation: using an API whose terms prohibit use in child-directed apps. Read each SDK's terms for child-directed restrictions and data use clauses. Keep a copy of the version you reviewed.
Step 4: Decide, and write it down
| Decision | When to use it |
|---|---|
| Keep | Needed, collects only what you expected, terms allow your use |
| Configure | Needed, but defaults collect more than necessary |
| Replace | A safer alternative exists with the same function |
| Remove | Not needed, or terms and data flows do not fit |
Record the decision, the date, and the reviewer. This record is what you show a district that asks.
Step 5: Make it recurring
Schedule a review for each release that changes the dependency list, and a full audit at least each term or quarter. A version bump can add new collection, so diff the inventory between releases and read what changed.
Try it yourself
Open the demo, find a package that appears as a child of another, and ask whether you would have noticed it without an inventory.
Click through it at your own pace, or open it full screen.
Safeguard provides SBOM and dependency scanning, and it has a free scan you can point at a repository for a first inventory.
Quick check
Do we need to audit SDKs that are open source?
Yes. Open source code runs with your app's permissions, and it can still collect or transmit data. Licensing and data behavior are separate questions.
How often should we repeat the audit?
Review on any release that changes dependencies, and do a full pass on a regular schedule such as quarterly.
Sources
Last reviewed: 19 October 2026.
