第三方 SDK 分类与风险识别
我刚做合规审计那会儿，拿到一份 SDK 清单就头大。几十个第三方库堆在一起，光看名字根本分不清谁在偷偷传数据。后来我养成了一个习惯——先把这些 SDK 按业务类型分个类。你想想看，广告类 SDK 和支付类 SDK 的隐私风险完全不是一个路数，混在一起没法审。
这一节我就把最常见的几种 SDK 类型拎出来，说说它们各自的功能、典型供应商，以及我实际项目中碰到过的坑。
1. 广告类 SDK
广告 SDK 是风险重灾区。说白了，它的核心逻辑就是“收集用户画像，匹配广告投放”。我见过的大部分广告 SDK 都会收集设备标识（IMEI、OAID、IDFA）、地理位置、应用列表、甚至用户行为序列。
- 常见供应商：Google AdMob、腾讯优量汇、穿山甲、快手联盟
- 典型风险：
- 超范围收集设备信息（拿到 IMEI 还要读取已安装应用列表）
- 未经用户同意向广告平台传输数据（特别是安卓端，很多 SDK 在启动时就开始上报）
- 使用非官方 API 获取 MAC 地址、AndroidID（我曾在某 SDK 里看到它通过
getMacAddress()硬取 MAC，这种行为工信部早就不允许了） - 与第三方数据共享未声明（比如把转化事件传给多个 DSP 平台）
审计要点：检查 SDK 初始化时机。广告 SDK 必须在用户点击“同意隐私协议”之后才能初始化，否则就是违规。
2. 分析类 SDK
分析 SDK 是内部运营的“眼睛”，但它能看的东西往往太多了。我记得有一次审计一个金融 App，里面的友盟 SDK 配置里竟然开启了“自动采集所有页面事件”，连用户在输入密码的页面停留多久都上报了——这明显越界。
- 常见供应商：友盟+、Firebase Analytics、GrowingIO、神策数据
- 典型风险：
- 默认收集完整埋点事件，未提供选择性关闭（比如“仅采集必要事件”开关）
- 使用不可逆哈希后仍能关联用户（有的 SDK 使用手机号/邮箱哈希后作为设备ID，本质上还是个人身份信息）
- 海外版与国内版数据流向混乱（Firebase 数据传到谷歌服务器，国内合规要求数据不出境）
- 错误调用时间戳：比如在
onCreate中直接调用Analytics.logEvent，此时用户尚未给授权
个人经验：我一般会要求客户端开发给分析 SDK 加一个“延迟初始化”开关，等用户同意隐私协议后才真正启动。代码里加个 if (ConsentManager.isAgreed()) { Analytics.init(); } 就行。
3. 社交类 SDK
社交 SDK 主要用于第三方登录、分享、邀请好友。风险点往往藏在“登录”和“分享”之外的附加功能里。我曾经在一个项目中看到微信 SDK 不但用了登录，还拉起了“附近的人”功能——这需要位置权限，而 App 本身根本不需要位置。
- 常见供应商：微信开放平台、QQ互联、新浪微博、Facebook SDK
- 典型风险：
- 社交 SDK 携带的额外权限（如读取联系人、位置），App 若未使用但未拒绝则违规
- 用户退出登录后，SDK 未清除本地缓存的 （导致其他应用可读取）
- 分享功能中传递了用户未授权的信息（例如分享图片时自动附带 GPS 位置标签）
- 通过回调获取用户手机号（部分 SDK 支持快速手机登录，但需要单独授权）
避坑指南：我曾经因为社交 SDK 的“自动获取用户资料”功能吃过大亏。微信 SDK 默认会在登录成功后调一次 getUserInfo()，返回用户昵称和头像。但如果你只做登录验证，根本不需要这个。审计时要确认调用链里没有隐藏的接口。
4. 支付类 SDK
支付 SDK 涉及资金交易，合规要求最严格。它收集的信息相对明确——订单信息、用户手机号、银行卡尾号等。但风险常出在集成的姿势上。
- 常见供应商：支付宝、微信支付、Apple Pay、银联 SDK
- 典型风险：
- 支付回调信息泄露：支付成功回调带有用户手机号、金额等，若日志输出则风险极高
- SDK 与支付平台之间传输未完全加密（很多人只用 HTTPS，但忽略对请求体的加密）
- 服务端与 SDK 之间缺少签名校验（容易被中间人篡改回调数据）
- 支付结果被第三方监听（比如某些推送 SDK 会截获通知栏，暴露支付状态）
审计要点：支付 SDK 的敏感行为（如发起支付、回调处理）必须在安全可信环境中执行。千万不要在 logcat 里打印支付参数。
5. 其他常见类型
| 类型 | 代表 SDK | 主要风险 |
|---|---|---|
| 推送 SDK | 极光推送、华为推送、Firebase Cloud Messaging | 收集设备标识 + 位置（部分推送为了精准推送会要求位置权限） |
| 地图 SDK | 百度地图、高德地图、Google Maps | 获取精确位置、用户轨迹记录（即使 App 不需要持续定位） |
| 崩溃分析 SDK | Bugly、Sentry、Firebase Crashlytics | 上报堆栈信息可能包含内存中的敏感数据（如密码字符串） |
| 客服/IM SDK | 融云、腾讯云 IM、美洽 | 聊天记录被第三方存储、未加密传输 |
风险识别框架：快速判断一个 SDK 是否危险
你拿到一个陌生的 SDK，怎么快速判断它有没有“雷”？我个人总结了四步检查法：
- 查文档：看它明确声明收集哪些数据。如果文档含糊其辞，直接跟开发要源码。
- 看权限：在 AndroidManifest 里搜这个 SDK 的包名，看它申请了哪些权限。如果不需要也能运行，说明权限申请可能有审查漏洞。
- 抓包：用 Charles 或 Wireshark 抓一下 SDK 初始化后的网络请求。我遇到过分析 SDK 偷偷传了 IMSI——这个数据它根本没必要拿。
- 看合规声明：SDK 版本更新日志里有没有提到“隐私政策更新”？没有的话，大概率不重视合规。
小技巧：把 SDK 解压后，用 grep -r "http\|\.txt\|\.json" packages/ 搜一下，能看到它内部调用了哪些接口。我经常这么干，能发现一些文档里没写的请求。
知识结构图：SDK 分类与典型风险
下面这张图帮你建立全局视角。圆圈节点是四类核心 SDK，方框节点是对应的主要风险，箭头表示风险关联。
总结一句话
SDK 分类是做合规审计的起点。你记住一个原则：每种 SDK 都有自己“顺理成章”的收集理由，但实际拿到的东西往往超过理由。我自己做审计时，永远会问一个问题：“这个数据这个 SDK 真的需要吗？” 如果答案是否定或模糊的，那就把它标红。