A useful SDK register has about twelve fields: name, version, purpose, owner, tier, data touched, permissions, network hosts, approval date, next review date, exceptions and exit plan. Keep it where engineers already work, generate what you can from builds, and review it on a schedule.
Why a register
Governance without a record is memory. When an advisory lands, you need to answer three questions fast: do we ship this, where, and who decides. A register answers them. It also lets you meet Apple's expectation that developers know the practices of third-party partners whose code they integrate and keep their privacy answers accurate.
The fields
| Field | Why it earns its place |
|---|---|
| Name and vendor | Identify it, including how it appears in lock files |
| Version shipped | The pinned version in each app |
| Apps and platforms | iOS, Android, which apps |
| Purpose | One sentence, so removal decisions are easy |
| Owner | A person, not a team alias |
| Risk tier | Drives review depth |
| Data touched | Types collected or read, mapped to store declarations |
| Permissions and entitlements | What the SDK needs the app to request |
| Hosts contacted | From your traffic test |
| Approval date and approver | The audit trail |
| Next review | Date, based on tier |
| Exceptions and exit plan | Expiry and how you would remove it |
Add a link to the vendor's data description and privacy manifest if one exists.
Generate, do not hand type
Hand typed registers go stale. Pull the facts that a build can supply, such as names and versions, from lock files or an SBOM, and keep humans responsible for judgement fields such as tier, purpose and data mapping. A nightly job that flags SDKs in builds but not in the register, or in the register but not in builds, keeps both honest. The CI allowlist uses the same data.
Transitive entries
Do not list every transitive library as a row. List the parent and record that its dependency set was reviewed at a version. Apple notes that SDKs which repackage listed SDKs fall under its requirement, which is a reminder that the tree matters even if the register shows only the parent.
Where to keep it
A file in the repo works well for small teams: it is versioned, reviewable and visible in pull requests. Larger organisations may prefer a tracked system with the same fields. Whatever the choice, one source of truth is better than three.
Try it yourself
Click through it at your own pace, or open it full screen.
Check which columns the inventory fills in for you, and which ones a person still has to add.
Safeguard's SBOM, asset discovery and dependency scanning can supply the factual columns, and compliance and evidence automation can keep the approval trail. A free scan is at gold.safeguard.sh/scan.
Quick check
Do we list transitive dependencies?
List the parent SDK and note that its tree was reviewed at a version. Use scanning to watch the tree.
How do we keep the register from going stale?
Generate factual fields from builds and compare the register with builds on a schedule.
Sources
Last reviewed: 19 October 2026.
