第三方SDK清单管理的重点，不是把供应商名称整理成一张表，而是持续回答四个问题：当前安装包里实际存在什么SDK和版本，它们在什么业务场景下处理哪些数据，公开披露与运行行为是否一致，以及新增、升级、异常和下线分别由谁负责。
一份可执行的台账应同时覆盖组件身份、用途、权限、数据、版本、处理关系、平台申报、责任人和核验证据。缺少其中任何一组信息，清单都可能在SDK升级或配置变化后失效。
第三方SDK清单管理到底要管理什么
第三方SDK清单至少存在两个不同用途，不能混为一张简单表格。
面向用户和平台的披露清单，用于说明App中嵌入了哪些第三方组件、由谁提供、用于什么功能，以及可能处理哪些个人信息。国家互联网信息办公室等部门发布的《App违法违规收集使用个人信息行为认定方法》将未逐一列出嵌入的第三方代码、插件或SDK及其收集使用个人信息的目的、方式和范围，列为监管认定时关注的情形。
企业内部SDK治理台账，还需要记录具体App、操作系统、组件标识、实际版本、初始化条件、权限调用、网络域名、审核记录、责任人、升级期限和下线状态。现行公开规则没有规定一套适用于所有企业的统一内部字段模板，因此这部分应被表述为企业治理设计，而不是法定统一格式。
公开披露清单强调用户能否理解，内部台账强调研发、安全、法务和采购能否核验。公开页面写着“用于故障诊断”，内部台账还应说明该SDK在哪个App版本中启用、什么操作会触发、传输哪些诊断字段、连接哪些域名、由谁批准接入。
第三方SDK清单也不等于SDK数据采集与埋点基础中的事件字典。事件字典回答业务行为如何被定义和上报，第三方SDK台账回答外部组件为什么被接入、实际处理什么数据、谁对版本和披露负责。对于用户行为分析SDK，两者可能存在字段关联，但不能相互替代。
用途、业务场景、权限和数据类型为什么必须分开登记
用途、场景、权限和数据类型经常被写在同一个单元格中，结果是任何一项都无法核验。
用途回答“为什么处理”，例如登录认证、消息推送、崩溃诊断或支付。用途不能只写成“改善体验”“优化服务”，因为这类描述不能限定具体处理范围。
业务场景回答“什么时候发生”。“用于登录”只是用途，“用户主动点击第三方账号登录时启动认证组件”才是可以检查初始化时机和数据范围的场景描述。
权限回答“组件可以访问什么操作系统能力”。权限不等于数据类型。获得位置权限不代表组件实际收集了权限覆盖范围内的所有数据；没有申请敏感系统权限，也不代表SDK完全没有处理个人信息。部分组件仍可能处理IP地址、App版本、设备型号、操作系统版本、网络状态或诊断信息。
数据类型回答“实际处理了什么”。内部台账只写“设备信息”通常不足以支持审核，应继续核对是否涉及设备型号、系统版本、网络信息、广告标识符、实例标识符或其他具体字段。对于分析类SDK，还要根据实际配置判断是否涉及事件名称、事件属性、用户属性、匿名ID、登录ID或Session标识，不能把某一分析产品的默认字段写成行业统一范围。
这些字段之间需要形成可验证关系：业务目的决定是否需要某项功能，具体场景决定何时初始化，功能实现决定是否需要权限，运行配置决定实际处理的数据。只要其中一项无法对应，就需要重新评估接入范围。
用责任与版本治理矩阵建立可执行台账
第三方SDK清单管理可以使用一张“责任与版本治理矩阵”作为核心信息资产。矩阵不只登记当前状态，还要保留判断依据和变更责任。
| 治理维度 | 建议登记字段 | 需要回答的问题 | 主要核验证据 |
|---|---|---|---|
| 组件身份 | SDK名称、供应商主体、包名、Framework名称、依赖坐标 | 安装包中的组件是否与清单指向同一对象 | 依赖文件、安装包分析结果、供应商技术文档 |
| 应用范围 | App名称、应用包名、iOS或Android、直接依赖或间接依赖 | 同一SDK在哪些应用和平台中实际存在 | 项目依赖、构建产物、代码仓库记录 |
| 功能与场景 | 主要用途、触发操作、是否必要、可选功能开关 | SDK为什么需要接入，在什么条件下启动 | 产品需求、初始化代码、配置说明 |
| 数据处理 | 数据大类、具体字段、用户标识、事件或诊断信息 | 当前版本和配置实际处理哪些数据 | 字段说明、运行日志、网络请求核验记录 |
| 权限与API | 系统权限、受限制API、申请时机、拒绝后的行为 | 权限是否与具体功能直接相关 | 配置文件、系统权限报告、调用代码 |
| 版本状态 | 当前版本、批准版本、问题版本、最后升级日期、停止维护日期 | 当前使用的是否为内部批准版本 | 锁定文件、构建记录、供应商版本说明 |
| 处理路径 | 本地处理或传出设备、接收域名、接收主体、保存期限、删除方式 | 数据流向是否与披露和合同一致 | 网络请求记录、服务协议、数据处理说明 |
| 处理关系 | 委托处理、共同处理、向其他处理者提供或待法务判断 | 企业与SDK提供方分别控制哪些处理目的和方式 | 合同条款、产品配置、法务审核记录 |
| 平台申报 | Apple隐私清单与签名状态、Google Play Data safety映射 | 应用商店申报是否覆盖当前第三方代码行为 | 提交后台记录、隐私清单、申报截图 |
| 责任与变更 | 业务、研发、安全、合规、采购负责人，评审单号和升级期限 | 发现差异或问题版本后由谁处理 | 审批记录、问题单、发布记录、整改记录 |
| 生命周期 | 拟引入、待评估、已批准、运行监控、待升级、待下线、已下线 | 组件当前处于什么治理状态 | 状态变更记录、下线验证、历史档案 |
矩阵中的“版本责任”是企业内部治理概念，不是现行法律中的统一术语。它要求团队把版本号与批准状态、审核人、升级期限、替代版本和回滚方案关联起来。
仅记录“当前版本为3.x”仍然不够。清单需要说明具体安装版本是否经过技术、安全和合规评审，是否存在已知问题，供应商是否已经停止维护，以及发现问题后由谁决定暂停发布、升级或替换。
哪些变化必须重新触发SDK复核
SDK完成一次准入评审，不代表后续版本可以自动沿用原结论。以下变化应进入重新复核流程：
- 新增组件或间接依赖：研发引入新功能时，应检查依赖树中是否同时加入了未单独评估的组件。聚合SDK和二次封装库不能只登记外层产品名称。
- SDK版本升级：比较新增权限、API调用、数据字段、网络域名、初始化方式、默认开关、隐私清单和供应商数据处理说明。
- 远程配置或功能开关变化：即使安装包中的版本号没有变化，远程开启广告、诊断、用户识别或其他模块，也可能改变实际数据行为。
- 初始化时机变化：检查SDK是否在用户完成相应选择前启动，关闭功能或撤回选择后是否仍继续请求网络或读取数据。
- 供应商主体、合同或数据接收方变化：供应商并购、分包关系、服务器区域或接收主体发生变化时，需要重新判断处理关系和披露内容。
- 平台警告或问题版本提示：出现Apple提交要求变化、Google Play SDK政策警告或供应商安全通知时，应关联受影响的App和版本。
- SDK下线：不能只从产品界面删除入口，还应验证代码、初始化逻辑、权限、缓存、网络请求和供应商侧数据处理是否同步停止。
每次变更至少应产生一条可追溯记录，包括变更原因、差异内容、评审人员、批准日期、隐私披露更新时间、应用商店表单更新时间和发布版本。具体项目如何划分职责、交付物和验收范围，可结合站内服务实施说明建立内部流程。
如何核对清单、安装包、运行行为和平台申报
第三方SDK清单不能只由采购资料或开发人员手工填报生成。更可靠的做法是核对六类证据：
- 代码仓库和依赖配置中声明的直接依赖；
- 最终安装包中实际存在的SDK、Framework和间接依赖；
- 操作系统权限配置、权限申请时机和受限制API调用；
- 初始化代码、功能开关和不同用户选择下的运行状态；
- 网络请求中的域名、接收主体和实际传输字段；
- 隐私政策、第三方SDK披露、Apple申报与Google Play Data safety表单。
这六类证据需要指向同一个App版本。用最新版隐私政策核对旧安装包，或者用供应商最新版文档解释企业仍在使用的旧SDK版本，都可能得出错误结论。
发现差异时，应先确定差异属于哪一类。安装包中出现未登记组件，属于识别覆盖问题；实际版本与批准版本不同，属于版本控制问题；网络请求包含未登记字段或域名，属于行为一致性问题；运行行为已经变化但隐私政策和商店表单未更新，属于披露同步问题。
不要把内部管理指标写成监管阈值
法规和平台规则没有规定统一的第三方SDK治理分数。企业可以使用内部指标观察管理状态，但必须注明口径和适用范围。
清单一致率＝用途、版本、权限、数据类型和供应商信息均与实际行为一致的活跃SDK实例数÷全部活跃SDK实例数。该指标应按App、平台、版本和配置计算，不能只按SDK品牌去重。
批准版本使用率＝当前使用内部批准版本的SDK实例数÷全部在用SDK实例数。这里的“批准”是企业内部技术、安全和合规评审结论，不代表监管机关或应用商店认证。
披露更新及时率＝在企业规定时限内完成清单、隐私政策和商店表单更新的变更数÷全部应更新的SDK变更数。具体时限应由内部制度确定，不能写成统一法定期限。
SDK供应商、App开发者和业务团队分别承担什么责任
“第三方SDK”只是技术来源描述，不能直接决定法律关系。根据实际控制方式，SDK提供方可能是受托处理者、共同处理者、独立个人信息处理者或个人信息接收方。
《中华人民共和国个人信息保护法》对委托处理以及向其他个人信息处理者提供个人信息设置了不同要求。企业不能因为组件由外部供应商提供，就统一写成“与第三方共享”，也不能在未核实处理关系时断言所有SDK都必须采用同一种同意方式。
业务团队需要证明功能目的和必要性；研发团队负责组件身份、版本、初始化、权限和配置；安全团队核对依赖、网络行为、漏洞状态和访问控制；法务或合规团队判断处理关系、告知授权、合同义务和用户权益安排；采购团队要求供应商提供版本说明、数据处理材料、变更通知和事件响应机制。
供应商文档可以作为评审输入，但不能代替企业核验。App使用了哪些模块、开启了哪些配置、传输了哪些字段，最终取决于企业的具体接入方式。
Apple在第三方SDK要求中明确，开发者需要对应用中的全部代码负责，包括第三方SDK代码，并应了解所使用SDK的数据实践。Apple的PrivacyInfo.xcprivacy、SDK签名和required reason API属于Apple平台规则，不能扩展为其他平台的统一标准。
Google Play的Data safety申报说明要求开发者将第三方SDK的数据收集和共享行为纳入申报，并对信息的完整性和准确性负责。Google Play SDK Index可以提供部分SDK版本、权限和政策提示，但并不覆盖所有组件，也不能替代安装包和运行行为验证。
隐私披露和商店表单为什么不能只在首次上线时填写
第三方SDK清单失效，常见原因不是首次接入时完全没有登记，而是后续版本变化没有同步到披露页面和应用商店表单。
一次SDK升级可能改变依赖包、权限、域名、数据字段或默认配置。即使产品界面没有变化，后台诊断、身份识别或网络请求行为也可能发生变化。因此，隐私政策、SDK公开清单、Apple App Privacy申报和Google Play Data safety表单都应与当前发布版本重新比对。
不能写成“只要隐私政策列出SDK就已经合规”。监管文件还关注是否逐一列出、描述是否准确、是否在取得相应同意前处理个人信息，以及实际处理范围是否超出声明。用户完成同意操作，也不代表SDK可以处理清单中可能涉及的全部数据，目的限定、最小必要、权限控制和安全措施仍需单独成立。
当SDK涉及敏感个人信息、未成年人信息、精确位置、联系人、设备标识、跨境处理或其他高风险场景时，应由内部法务、个人信息保护负责人和安全团队结合具体功能进一步评估。文章中的一般说明不能代替针对具体应用的法律意见或平台审核结论。
适用范围与最后核实日期
上述方法适用于企业自有App中的第三方SDK治理，不涵盖未经授权采集、绕过用户选择、非法读取通讯录、滥用设备标识或抓取竞争对手数据等行为。技术验证应限定在企业有权管理的应用、账号、设备、代码和数据范围内，并落实明确目的、透明告知、合法授权、最小必要、数据脱敏、权限控制和安全措施。
涉及中国监管和Apple、Google平台规则的内容，依据已核实资料截至2026年7月28日的官方页面记录。Apple和Google部分帮助页面未标注统一更新时间，正式发布文章或调整SDK清单前，应重新访问官方页面核对。
2026年公开的《互联网应用程序个人信息收集使用规定（征求意见稿）》提出SDK名称或包名、版本、主要功能、运营者、个人信息类型、规则链接和历史版本管理等方向。截至上述核实日期，只能确认该文件属于征求意见稿，不能写成已经生效的统一强制要求。
开始整理清单时，可以先准备当前App列表、依赖文件、安装包、权限报告、初始化说明、网络请求记录、隐私政策和商店申报截图，再由研发、安全、法务和采购共同填写责任与版本治理矩阵。材料准备和常见边界问题可继续查看SDK采集与分析常见问题。
判断一份第三方SDK清单是否可用，可以检查它能否准确指出：某个具体App版本正在使用哪个SDK版本、为什么使用、实际处理什么数据、由谁批准，以及下一次变化由谁重新核验。无法回答这些问题的清单，只能算静态目录，还不能承担版本治理和合规复核任务。