A third-party SDK may process data and make connections with the application's privileges. Being a security product does not exempt it from supply, data and update-risk review.
Evaluation approach
Assess package integrity, version changes, outbound data and build effects. Signature or digest verification can support the integrity of the acquisition channel.
Application example
Compare a new SDK release's network domains and collected event fields with those of the prior release.
Limits and considerations
A familiar vendor name does not guarantee that every release behaves identically.
A dependency runs in the same process
Third-party SDKs can access application data and privileges. Security components also need inventory, licensing, update and data-flow review. Their product category is not proof of trustworthiness.
Compare new permissions, network destinations and native libraries between releases. Be able to identify affected application versions after a vendor incident. The delivery chain of a RASP-protected application needs its own protection.
Checks and decisions
- Pin dependencies
- Read release notes
- Observe data flows
Account for the supply and operational dependencies introduced by a RASP integration.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.