Third-Party SDK Risk

Third-party SDKs , software development kits provided by analytics, advertising, customer support, and feature enrichment vendors , are pre-built code libraries that mobile and web applications integrate to access specific functionality without building it from scratch. When an application integrates an SDK, it incorporates code that runs within the application's process, has access to the application's data, and may collect data from the device or the user without the application developer's complete awareness of every data collection behaviour. SDK risk is a supply chain risk category that sits at the intersection of security, privacy, and regulatory compliance , and is frequently underassessed because SDK integrations feel more like feature additions than third-party vendor relationships.

The SDK update mechanism is the specific supply chain risk. SDKs are updated by their providers and incorporated into applications through dependency management. When an SDK provider changes the data collection behaviour of their SDK in an update , adding new device identifiers, expanding behavioural tracking, or enabling new network transmissions , that change propagates to every application that updates to the new SDK version. Application developers who update SDKs as part of routine dependency maintenance may not review the SDK changelog in sufficient detail to identify privacy-relevant behaviour changes before releasing the updated application.

The acquisition trigger is a specific high-risk event for SDK governance. When an SDK provider is acquired, the acquiring company's data interests and privacy practices may differ from the original provider. The new owner may update the SDK to collect additional data that serves the acquiring company's business model. Application developers who track the SDK provider for changes may miss an acquisition-triggered SDK update if they are not monitoring the SDK's ownership and corporate structure alongside its technical behaviour.

Why this matters

SDK risk matters for TPRM because SDKs in enterprise mobile and web applications create data collection and transmission risks that the enterprise may not be fully aware of , and that change over time as SDK providers update their products. Privacy regulation , GDPR, CCPA, COPPA , requires that enterprises disclose and have a legal basis for all personal data collection, including data collected by embedded SDKs. An SDK that collects data beyond what the enterprise's privacy policy discloses creates immediate regulatory exposure.

• SDK evaluated at integration without ongoing monitoring
• SDK update behaviour changes not reviewed before incorporating updates
• Provider acquisition not identified as SDK governance trigger event
• Privacy policy alignment with SDK data collection not continuously verified
• Network traffic analysis absent from SDK behaviour assessment

What good looks like

Mature SDK governance programmes maintain a current SDK inventory with data collection behaviour documentation, monitor SDK updates for privacy-relevant behaviour changes before incorporating them, identify provider ownership changes as trigger events for SDK re-evaluation, and verify privacy policy alignment with actual SDK data collection behaviour.

• SDK inventory with data collection behaviour documentation
• SDK update changelog review for privacy-relevant behaviour changes
• Provider acquisition monitoring as SDK re-evaluation trigger
• Privacy policy alignment verification , actual collection vs disclosed collection
• Network traffic analysis to verify SDK data transmission behaviour

Tooling

SDK Analysis , Exodus Privacy for Android SDK analysis; Charles Proxy, mitmproxy for network traffic analysis

SDK analysis tools can assess the data collection and network transmission behaviour of mobile SDKs , identifying what data the SDK accesses and where it transmits it. Network traffic analysis during SDK testing reveals actual transmission behaviour that may not be documented in the SDK provider's privacy documentation. For TPRM practitioners, asking whether vendors have conducted network traffic analysis of their SDK integrations as part of the integration review provides a specific SDK behaviour assessment question.

Governance challenges

The governance challenge with SDK governance is the development workflow integration requirement. SDK update review must be integrated into the development process at the point of dependency update , not conducted as a separate security review after updates are incorporated. The governance resolution is SDK-specific changelog review requirements in the development workflow, triggered by any SDK version update in the dependency manifest.

• Require SDK changelog review before any SDK version update is incorporated
• Monitor SDK provider ownership for acquisitions and mergers
• Verify privacy policy alignment with SDK data collection after each update
• Conduct network traffic analysis for SDKs with significant data collection
• Include SDK governance in mobile and web application security assessment

If you are a small team

Create an inventory of all third-party SDKs in your mobile and web applications. For each SDK, document what data the SDK provider's documentation says the SDK collects and transmits. Then verify that your privacy policy discloses all of that collection. For your advertising and analytics SDKs , the highest-risk categories for unexpected data collection , run a network traffic intercept test to confirm that the actual data transmission matches the documentation. That inventory and verification process identifies the SDK data collection risk the integration evaluation identified at a point in time but continuous monitoring does not track.

• Inventory all third-party SDKs with documented data collection behaviour
• Verify privacy policy alignment with SDK data collection documentation
• Monitor SDK provider ownership for acquisitions
• Conduct network traffic analysis for advertising and analytics SDKs

What to require

Ask directly:

"Can you provide documentation of all third-party SDKs integrated in your application , specifically what data each SDK collects and transmits , and how do you identify and review privacy-relevant behaviour changes in SDK updates before incorporating them into your product?"

Expect as evidence

• SDK inventory with data collection behaviour documentation
• SDK update review process for privacy-relevant changes
• Privacy policy alignment confirmation
• Network traffic analysis results for high-risk SDKs

A vendor who confirms application security should be asked about SDK inventory and ongoing governance. SDK evaluation at integration confirms the behaviour at that point. Ongoing update monitoring and ownership tracking are required to catch the behaviour changes that occur after integration.

How to evidence it

• SDK inventory with data collection documentation
• SDK update review records
• Provider ownership monitoring records
• Privacy policy alignment verification

Key Takeaway

SDK: evaluated at integration. Provider: acquired 18 months later. SDK update: new data collection capabilities. Enterprise privacy policy: not updated. Regulatory exposure: immediate. SDK evaluation at integration captures the behaviour at one point in time. The supply chain risk in SDKs is the behaviour that changes after integration , through SDK updates, provider acquisitions, and new feature additions that expand data collection beyond the original assessment scope. Update changelog review, ownership monitoring, and privacy policy alignment verification are the continuous governance mechanisms that catch what point-in-time assessment cannot.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security