App安全合规的思考（六）SDK合规 – 作者:Moench-安全小百科

App安全合规的思考（一）：APP安全认证的工作流程梳理
 App安全合规的思考（二）监管的重点变化梳理
 App安全合规的思考（三）如何做好App整改应急响应工作
 App安全合规的思考（四）权限问题
 App安全合规的思考（五）隐私合规产品调研
 App安全合规的思考（六）SDK合规

0 前言

软件开发工具包（Software Development Kit，简称SDK）因其可以简化开发提高运营效率近几年被广泛使用，但因SDK提供者安全意识淡薄、市场监管力度低，从而出现安全漏洞、恶意行为、违法违规收集用户个人信息等安全问题

自2020年315晚会爆第三方开发的SDK违规收集用户个人信息的情况后，监管力度才逐渐加强。虽然监管重心依旧在App开发及应用平台方，但迫于App接入方和监管方压力，SDK提供方也在积极配合整改，如设立SDK合规专区、增强提示告知开发者完成合规指引、更新合规性SDK等等。

1 参考

参考为什么前边，不放文末？因为重要呀。

本文主要参考一下三个规范，里边有很多详细的内容，在下文中没有摘出来特别说明，可以提前下载学习。

《信息安全技术　移动互联网应用程序（App）SDK安全指南征求意见稿》

《移动互联网应用程序（App）使用软件开发工具包安全指引》

《软件开发包sdk安全与合规报告2020》

2 SDK分类

目前从功能性划分，有分享、支付、推送、统计、广告、地图等，但同一个公司有很多业务开发人员不同，选择接入的厂商不同，可能会导致同功能类型的接入了很多，解决办法可以考虑建立SDK管理机制（相信公司都有供应商管理机制，套用下）。

为了方便App开发者，有些SDK提供者聚合了同功能但又不能互相替代的SDK，形成了新的SDK，如xx社会化分享SDK（微博、微信、QQ等）、xx推送（小米推送、华为推送等）、x验（移动、联通一键等登录等）。

此外，还要单独提一类聚合类SDK——渠道联运SDK，主要集成了账号SDK、支付SDK，还有数据后台统计等功能。但是每个App如果要上不同渠道，都需要接入该渠道指定的SDK。

3 目前遇到的问题

SDK存在违法违规收集用户个人信息以及索权情况肯定是根本问题，这里列出的是这一根本问题引发的一些连带问题。

SDK提供方缺乏合规专业人员，对于SDK的合规性把控力度不够；

SDK提供方合规性动作滞后，很多是接入方推动其整改，并且部分SDK提供方整改配合度不够；

SDK提供方对其SDK合规性的披露颗粒度不够（华为写得就很好，权限和个人信息一目了然）

SDK接入方隐私政策披露颗粒度存在问题，SDK外接的SDK是否需要披露；

SDK版本在迭代，如何保障持续性合规；

App上n渠道，上架前要打不同的渠道包，最后每个App就会有N个，如何保证每个包体的合规；

4 解决方案

4.1 背景

在说解决方案之前，先来看一下一个App的组成情况，以渠道游戏包为例：

通过上图可以清晰的划分为：渠道SDK（其实也是第三方SDK，但渠道SDK在各个渠道不同）、第三方SDK、自研SDK，可通过分别对渠道SDK、母包、自研SDK、第三方SDK进行把控。

4.2 及时更新

其实，现在很多家SDK提供者都在为了更合规而优化产品，SDK迭代的速度很快，保持SDK的随时更新并参见其定制的合规指南，可以解决一部分合规问题。

4.3 安全评估

虽然问题很多，但是解决办法始终是一样的——做安全评估，推动提供者整改，在公司内把控接入。《移动互联网应用程序（App）使用软件开发工具包安全指引》里还列了其他8想，详见5.2 App 提供者安全措施的内容。

SDK安全评估

来源性评估：包括但不限于:SDK提供者的基本信息；SDK提供者的沟通反馈渠道；SDK隐私政策链接地址；提供者的安全能力；SDK的基本功能；SDK的版本号等。

代码安全性评估：是否存在已知的恶意代码;是否存在已知的安全漏洞；是否申请敏感权限；是否嵌入了其他SDK等。

行为安全性评估：调用的敏感权限、目的和频率;收集的个人信息类型、目的和频率；个人信息回传服务器域名、IP地址、所在地域；是否在热更新行为及热更新是否可主动关闭；传输数据是否加密；是否存在单收集用户个人信息的界面；是否存在后台自启动和关联启动后收集个人息的行为等。

对集成后的SDK进行持续动态监测或定期进行安全评估。

4.3.1 来源性评估

针对在用SDK进行基本信息梳理，包括：SDK名称、版本、公司名称、公司资质、是否签署数据处理协议、隐私政策、合规指南、SDK安全性资质、沟通回复速度、是否有发生过安全事件等。

根据这些信息就可以有些动作了，比如没有隐私政策的沟通SDK提供方添加，回复速度慢（不配合）尽量业务推动暂停使用……

这个步骤获取的信息还可用于隐私政策披露。

4.3.2 代码安全性评估

（我是菜鸡，不会审代码，并且是合规篇，这个先忽略吧）

4.3.3 行为安全性评估

Step1：针对4.1.1中来源性评估，从SDK提供方获取权限及个人信息收集的情况。

Step2：对SDK打DEMO包逐一进行测试，主要关注权限索取、个人信息收集情况（同意前、同意后）。

Step3：比对合规指南披露的情况与实际情况是否一致，实际情况只能比官方披露的少不能多。

通过上述三种评估的评估结果，即可对SDK有了一个初始的判定，合规SDK接入，不合规SDK整改或拒绝接入。

4.4 《隐私政策》对使用第三方SDK的使用情况披露详尽

对第三方SDK的基本情况调研（网站、合规指南、数据处理协议等等）获取的信息+测试结果信息，就是最终需要对外披露的信息了，这里会存在披露颗粒度的问题，是披露到大类还是到字段需要自己把控。

《信息安全技术　移动互联网应用程序（App）SDK安全指南》中附录D给出了一个披露第三方SDK的示例表格（很细），包括SDK名称、命名空间、公司名称、SDK用途、收集个人信息、申请权限情况、隐私政策链接。

4.5 持续性合规

指南说对“集成后的SDK进行持续动态监测或定期进行安全评估”，一般触发安全评估是在SDK版本发生变化的时候。当然还可以根据情况增加一起触发安全评估的场景，如接入方式发生变化、年度评估等等。

4.6 形成管理机制

如果有额外人力，可以趁热打铁，和公司供应商管理一样，制定一套SDK管理机制，包括SDK准入、SDK评估、SDK退出等等过程。

统一管理第三方SDK有如下好处：

可以随时了解业务SDK接入情况。

减少测试、管理、推动整改等人力成本。

既能优质SDK全公司共享，还可以较少支出成本。

……

5 碰到过的关于SDK的问题

5.1都是在接入第三方SDK，有些被认定为为委托处理有些被认为是共享，怎么区分？

有些SDK提供者确实不好区分，根据《软件开发包SDK安全与合规指南》中5.2.1的解释，认定“当第三方 SDK 可以直接透过 App 露出自己品牌时，App 开发者更容易让 SDK 提供方独自成为个人信息的数据控制者，应当在 App 《隐私政策》的共享章节或者展示 SDK 的专门章节介绍 App 接入了哪些具体的第三方 SDK、向这些第三方 SDK 共享个人信息的目的、功能、范围、开启权限等情况、第三方 SDK 的隐私政策情况(如有);如果在披露第三方 SDK的隐私政策时，可实现跳转至第三方 SDK官方服务页面的，建议向用户直接展示该第三方 SDK 的《隐私政策》。”

白话就是，有品牌露出就认定为数据共享，没有品牌露出就认定为数据委托处理。比如使用三方登录跳转到第三方App、再比如分享会跳转到第三方App。