Review a third-party SDK before an outsourced integration

Is the handoff ready?

Use these checks before access expands or the first ticket begins.

Name the capability the SDK provides

Start with the capability the product needs, such as payments, maps, analytics, or authentication. Then ask whether a direct API call or a small internal module would meet the need with less dependency. An SDK is justified when it removes meaningful complexity, not when it merely saves an afternoon. Write the justification in the ticket before the integration begins.

List the SDK surface the team actually plans to use, including the initialization, the main calls, and the error handling. A large SDK often exposes far more than the product needs, and every exposed surface is another thing to review. Ask the vendor whether the unused modules can be excluded from the build. The smallest useful surface is easier to secure and easier to replace.

Check the license and distribution terms

Read the license that applies to the exact version the team plans to ship, not the marketing page. Check whether the license requires attribution, disclosure, or a particular distribution model. Some licenses are compatible with a hosted service but not with a mobile app that embeds the code. Record the license name and the version in the integration ticket.

Review the vendor's terms for data use, telemetry, and support. A free tier may include usage analytics that the client has not approved. If the terms allow the vendor to change the data practice with notice, record how the team will monitor that change. A license review that stops at the word open source is incomplete.

Review the data the SDK can access

List the data the SDK can read from the device or the application, including identifiers, location, contacts, and files. Compare that list with the data the feature actually needs. If the SDK requests more than the feature uses, disable the extra permissions or choose a different tool. Record the permission configuration in the code review.

Inspect the network calls the SDK makes during a test session. A tool that phones home on initialization may send data before the user has consented. Use a proxy or the platform's network inspector and save the redacted results. If the calls cannot be explained, do not ship the integration until the vendor provides an answer.

Test the failure and offline behavior

An SDK that works only on a fast, authenticated network is a production risk. Test what happens when the network is slow, the token expires, the permission is denied, and the service returns an error. Record the behavior and the message the user sees. The integration should fail in a way the product can recover from.

Test the offline path if the feature is used on a mobile device or in a location with unreliable connectivity. Decide whether the SDK queues work, drops it, or blocks the interface. A queue that grows without a limit can become a data problem later. Record the chosen behavior and the owner who approved it.

Check the update and support path

Ask how often the SDK releases, whether it follows semantic versioning, and how breaking changes are announced. Check the issue tracker and the release notes for the last year. A package with no recent maintenance is a liability even if it works today. Record the maintenance signal and the date it was checked.

Name the person who will own upgrades and the cadence for reviewing them. An SDK that is installed once and never updated becomes a security and compatibility problem. Add the upgrade to the maintenance calendar before the first release. If the vendor requires a paid support plan for security fixes, include that cost in the decision.

Measure the bundle and runtime cost

Measure the size the SDK adds to the build and the time it adds to startup. Compare the result with the product's performance budget and with the cost of a direct integration. A small feature that doubles the bundle may not be worth the dependency. Record the measurement method and the environment.

Check the runtime cost during the operations the feature performs, not only at startup. A library that blocks the main thread during a common action will hurt the user experience. If the cost is acceptable, record the budget and the monitoring that will catch a regression. If it is not, revisit the direct API option.

Record the decision and the exit plan

Write a short decision record that names the capability, the alternatives considered, the license, the data access, the measured cost, and the owner. Include the conditions under which the team would replace the SDK. A decision record is more useful than a comment in a pull request because it survives the integration. Link the record from the integration ticket so the next engineer can find it.

Define the exit plan: which module wraps the SDK, which tests cover the integration, and what a replacement would need to implement. Keep the SDK behind an internal interface so the rest of the code does not depend on its types. An exit plan written before adoption is cheaper than a migration written after a vendor change. Review the wrapper boundary at the first code review, before the SDK leaks into unrelated modules.

Re-review after the first production month

After a month in production, review the SDK's actual behavior against the assumptions in the decision record. Check the error rates, the network calls, the bundle size, and the support tickets. If the assumptions were wrong, update the record and decide whether to keep, constrain, or replace the SDK. If the review finds no issues, record that result as well so the next review has a baseline.

Review the vendor's release notes and security advisories for the period. If a new version is available, decide whether to upgrade now or schedule it. Record the decision and the next review date. A due-diligence review that ends at adoption becomes stale as soon as the vendor ships a change.

Frequently asked questions

Sources

1. Open Source Initiative, licenses

   License texts and compatibility considerations.

2. NIST Secure Software Development Framework

   Supply-chain and third-party component practices.

3. CISA Secure by Design

   Expectations for secure defaults and vendor transparency.