Review approved SDKs on a calendar and on triggers. A reasonable calendar is quarterly for high risk SDKs, twice a year for medium and yearly for low. Triggers include a major version, a security advisory, a vendor ownership or terms change, and a new data practice.
Why approval expires
An approval describes one version on one day. SDKs change: new features, new dependencies, new network calls, new owners. Android Studio itself warns when a dependency is outdated, violates Play policies, has known vulnerabilities or is deprecated, and Android's guidance says outdated versions could keep you from publishing in future. The approval you gave last year did not see any of that.
Calendar reviews
| Tier | Frequency | Depth |
|---|---|---|
| High | Quarterly | Advisories, release notes, traffic diff, data declaration check |
| Medium | Twice a year | Advisories, release notes, maintainer health |
| Low | Yearly | Advisories and last release date |
Tiers come from our risk tier guide. Pick a fixed month so the review does not drift.
Trigger reviews
Start an off cycle review when any of these happens:
- The SDK ships a major version.
- A published advisory affects your version.
- The vendor changes owner, licence or terms of service.
- A privacy manifest or data description changes.
- Maintenance stops, for example no release in a long period relative to the tier. See abandoned SDKs.
- A store or platform changes its requirements.
A 20 minute agenda per SDK
- Is the SDK still used? If not, schedule removal.
- Which version do we ship, and what is the latest?
- Any open advisories or breaking notices?
- Any change in permissions, hosts or data collected?
- Is the owner still the right owner?
- Decision: keep, upgrade, replace or remove. Record it with a date.
Time box the meeting. Do the reading beforehand, with a one page summary generated from the register.
Make the review cheaper
Automate what you can. Continuous scanning flags new advisories between reviews, so the calendar session spends time on judgement, not discovery. Keep the register accurate so the review starts from facts, and let CI block unapproved additions so the list does not grow unseen.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how new findings appear for components that did not change. That is why a one time approval is not enough.
Safeguard's dependency scanning and policies support this kind of continuous check. A free scan is at gold.safeguard.sh/scan.
Quick check
Is quarterly too often for every SDK?
For all of them, yes. Reserve it for high risk SDKs and use triggers for the rest.
Who runs the review?
The SDK program owner, with security and privacy providing input for the high tier.
Sources
Last reviewed: 19 October 2026.
