A good SDK approval workflow has five steps: a short request, a risk triage, a proportionate review, a recorded decision, and an entry in a register. Small SDKs get a fast path. SDKs that touch user data, networking or code loading get the full review. Every decision is written down.
Why mobile teams need a workflow at all
Once an SDK ships inside an app, you are responsible for the code it brings. Apple states this plainly on its third-party SDK page: when you use an SDK, you are responsible for all the code it includes and need to know its data collection and use practices. That sentence applies to every SDK, listed or not. A workflow is how a team makes that responsibility visible before a release, not after a store question.
The five steps
| Step | Who | Output |
|---|---|---|
| 1. Request | Any developer | Name, version, purpose, alternatives considered |
| 2. Triage | Security champion | Risk tier (see below) |
| 3. Review | Security, privacy, maintainers | Findings and conditions |
| 4. Decision | Named approver | Approve, approve with conditions, or decline |
| 5. Register | Request owner | Entry with owner, pinned version, review date |
Request. Keep the form to a handful of fields. Ask what the SDK does, which app and feature need it, and what happens if you build the feature in house instead. A request that cannot explain the need is usually a request to decline.
Triage. Decide the tier in minutes. Does the SDK collect personal data, make network calls on its own, load code at runtime, or request permissions? Any yes moves it to the full path. A pure UI helper with no network access takes the fast path.
Review. The full path covers the maintainer and release history, known advisories, transitive dependencies, permissions, network destinations and the data it declares. Our vetting checklist lists the checks in detail.
Decision. One named person approves. Committees slow things down and dilute ownership. Conditions are fine, for example "approved on version 4.2 only, analytics collection disabled".
Register. The approval is not finished until the SDK is recorded with an owner and a pinned version. Without that, the next person cannot tell who to ask.
Keep the fast path honest
The fast path exists so the process does not become a reason to bypass it. Write down what qualifies, and sample a few fast path approvals each quarter to confirm they still qualify. If developers routinely argue a risky SDK onto the fast path, tighten the triage questions rather than adding more reviewers.
Make it enforceable
A workflow nobody checks is a suggestion. Add a check in CI that fails when a dependency appears that is not in the register, as described in blocking unapproved dependencies in CI. Pair the decision with a version rule so approval means a specific version, not whatever resolves next month.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the inventory and notice how many components arrive that nobody requested directly. Those are the ones a request form never sees.
Safeguard can help with the inventory side: SBOM and dependency scanning list what a build actually contains, and policies can gate new components. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Who should approve a new SDK?
One named approver, usually a tech lead or security champion, with privacy consulted when personal data is involved.
Does every SDK need a full review?
No. Triage first. Low risk libraries with no network, data or permissions can take a short path, as long as they still get recorded.
Sources
Last reviewed: 19 October 2026.
