Before embedding a partner's SDK, ask what data it collects, which permissions it needs, what dependencies it brings, how updates are delivered and how you can remove it. An SDK runs inside your application with your privileges, so its flaws become your flaws, and your customers will see your name, not theirs.
Why an SDK is different from an API
An API call crosses a boundary. You choose what to send. An SDK sits inside your process. It can read memory your code can read, use permissions you granted the app, make network calls to hosts you did not pick, and pull in packages you never reviewed.
Ten questions
Data
- What data does the SDK collect or transmit, and to which hosts? Ask for a list of domains.
- Can collection be switched off or limited by configuration?
Permissions and behaviour 3. What permissions does it need on each platform, and why? 4. Does it run background tasks, load remote code or fetch configuration at runtime?
Dependencies 5. Can you send an SBOM for each SDK release, including transitive packages? 6. Does it bundle copies of open source libraries, and under which licences?
Updates and support 7. How are security fixes announced, and how fast do releases follow? 8. Which versions are supported, and for how long?
Control and exit 9. Is the integration isolated behind your own interface, so you can swap it? 10. What happens to your data if the partner is acquired, changes terms or shuts down?
How to test the answers
- Build a test app with the SDK and record its network traffic. Compare hosts with the list you were given.
- Scan the built artifact, not just the manifest. See how to tell if an SBOM is complete.
- Diff the permissions in your app before and after.
- Read the release notes for the last four versions. Do they mention security fixes plainly?
Decision table
| Result | Action |
|---|---|
| Traffic matches the list, SBOM provided | Proceed, pin the version |
| Extra hosts appear | Ask for an explanation before shipping |
| Remote code loading | Review closely, consider declining |
| No SBOM, no release notes | Treat as higher risk, ask again |
Keep the exit door open
Wrap the SDK in a thin adapter of your own. If the partner has an incident or disappears, you change one module instead of rewriting features. Pin the version in a lockfile and review every upgrade as you would a new dependency.
Try it yourself
Open the demo to see how a project's dependency inventory exposes packages that arrive with an integration. Look for entries you did not choose directly.
Click through it at your own pace, or open it full screen.
Safeguard scans dependencies and builds SBOMs for web and mobile projects, so you can see what an SDK adds. A free scan is a quick first look.
Quick check
Is an SDK from a well known partner automatically safe?
No. Reputation helps, but the questions above still apply to every SDK.
Do I need legal review too?
Yes for data handling and licensing terms. This post is not legal advice.
Last reviewed: 19 October 2026.
