Every SDK in a fintech app runs with the same access as your own code. Before adding one, check what data it can read, where it sends it, how it is updated and how you would remove it. Pin versions, review changes, and keep an inventory so a vendor incident becomes a lookup, not a hunt.
Why SDKs deserve special care
A mobile or web SDK is usually closed or lightly reviewed, ships often and can phone home. In a money app the data nearby is account numbers, balances, device identifiers and session tokens. A bug or a bad update in a small analytics library reaches all of it.
Before you add one
Ask these and write the answers on the ticket.
- What data does it collect by default, and can we turn collection off?
- Does it send data to servers we do not control? Which ones?
- What permissions does it request on the device or in the browser?
- Who maintains it, and how are security issues reported and fixed?
- What does it pull in as dependencies?
- Can we do the same job with a smaller piece of code or a server side call?
If an answer is unknown, treat it as a risk, not a pass.
While it is in your app
Pin exact versions and commit the lockfile. Update on purpose, with a diff review of the changelog and the dependency tree, not on autopilot. For web SDKs loaded by script tag, avoid unpinned remote URLs on pages that handle sensitive input. Use subresource integrity where the vendor supports fixed files.
Keep an SBOM of every release so you can answer, within minutes, "which builds contain version X of that SDK". Dependency scanning on each pull request flags known flaws in the SDK and what it pulls in.
Limit what it can touch
Initialise SDKs after login only if they do not need to run earlier. Give them scrubbed identifiers rather than raw account numbers. Keep payment or sensitive input in the vendor's hosted fields or your own code, never in a general analytics wrapper. Check your logs and crash reports for personal data that an SDK might capture.
Plan the exit
Write down how you would remove the SDK and what breaks. If removal needs a quarter of work, that dependency has more power over you than you thought. Review the inventory twice a year and delete what nobody uses.
Where Safeguard fits
Safeguard's SBOM and dependency scanning, policies and gates can flag risky SDK versions in pull requests, and reachability analysis shows whether a vulnerable function in the SDK is actually called. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a signed, well known SDK safe by default?
No. Reputation does not remove the need to check data collection, permissions and update behaviour.
How often should we review our SDK inventory?
Twice a year is a reasonable starting point, plus a review whenever a vendor reports an incident.
Last reviewed: 19 October 2026.
