2. SDK资产盘点与分类分级
SDK治理的第一步不是制定规范，而是回答一个更基础的问题：我们到底有哪些SDK、它们在哪里、由谁引入、版本是什么、被谁使用。如果连资产清单都不准确，后续的许可证合规、漏洞响应、版本收敛和供应链安全都无从谈起。SDK资产盘点的目标，是建立一份可持续更新、可追溯、可分级治理的SDK资产台账。
一、资产发现：三条互补的发现路径
SDK不会主动登记自己，必须通过多种手段交叉发现。实践中通常组合三条路径：
- 代码仓库扫描：对源码和构建脚本进行静态分析，识别依赖声明文件（如
package.json、pom.xml、build.gradle、requirements.txt、go.mod）以及直接引入的二进制文件（.jar、.aar、.so、.dll、.framework）。这是最准确的“声明层”来源。 - 制品与运行时扫描：对构建产物、容器镜像、移动端安装包（APK/IPA）进行成分分析（SCA），识别实际打包进去的SDK及其版本。声明层与制品层经常不一致，例如传递依赖、手动拷贝的库、动态加载的插件。
- 流程与人工登记：通过采购记录、法务合同、应用商店后台、第三方合作清单补充“非代码引入”的SDK，例如统计、广告、推送、支付类SDK，它们往往由业务或商务团队引入。
三条路径的发现结果需要合并去重。建议以“SDK名称 + 版本 + 引入方式 + 所在制品”作为唯一键，避免同一SDK因不同仓库、不同构建方式被重复计数。发现阶段还应记录“发现来源”，便于后续判断资产的可信度。
二、元数据模型：让每个SDK可描述、可比较
资产台账的核心是元数据模型。一个可用的SDK元数据模型至少应覆盖以下维度：
| 维度 | 字段示例 | 用途 |
|---|---|---|
| 标识 | SDK名称、供应商、包名/坐标、版本号 | 唯一识别与去重 |
| 来源 | 引入方式、引入仓库、引入人/团队、引入时间 | 追溯责任与变更 |
| 技术属性 | 语言/平台、依赖关系、许可证、是否传递依赖 | 兼容性与合规判断 |
| 使用属性 | 被哪些应用/服务使用、调用量、关键程度 | 影响面评估 |
| 风险属性 | 已知漏洞、维护状态、供应商可信度、数据采集行为 | 分级与处置优先级 |
| 治理属性 | 责任人、审批状态、允许版本范围、替代方案 | 持续治理与收敛 |
元数据模型不必一次求全，但必须保证“版本、许可证、使用方、责任人”四个字段的准确性，否则分级结果会失真。建议为每个字段定义数据来源和更新频率，例如版本号来自SCA扫描，责任人来自服务目录，许可证来自SBOM解析。
三、分类分级标准：从“是什么”到“怎么管”
分类解决“它属于哪一类”，分级解决“它需要多严的管理”。分类可按功能域划分，例如：基础框架、网络通信、数据存储、日志监控、安全加密、UI组件、支付、推送、广告、统计分析、AI/ML。分类的价值在于同类SDK可以统一策略，例如广告类SDK通常涉及隐私合规，安全类SDK需要更严格的漏洞响应。
分级则依据风险与影响面。一个可落地的分级标准可以综合以下因素：
- 数据敏感度：是否接触用户隐私、支付信息、设备标识、位置等。
- 运行位置：是否运行在客户端、服务端、边缘节点，是否可被外部输入触发。
- 影响范围：被多少应用/服务依赖，是否处于关键链路。
- 供应链风险：供应商是否活跃维护、是否有历史漏洞、许可证是否高风险。
- 可替代性：是否有成熟替代方案，替换成本高低。
例如，可将SDK分为四级：L1核心关键（如安全加密、支付核心，需强审批、强监控、版本锁定）；L2重要业务（如网络框架、推送，需定期扫描、版本收敛）；L3一般支撑（如日志、UI组件，按季度盘点）；L4低风险/可替代（如小型工具库，允许自主引入但需登记）。分级不是永久标签，应随使用场景和风险变化动态调整。
四、盘点工具链：从扫描到台账的流水线
工具链的目标是让盘点自动化、可重复。典型链路包括：
- 采集层：使用SCA工具（如 Dependency-Check、Trivy、Syft、Grype）扫描仓库与制品，生成原始成分清单。
- 归一化层：将不同工具的输出统一映射到元数据模型，处理包名别名、版本范围、许可证标准化。
- 存储层：写入SDK资产库（可用关系型数据库或图数据库），保留历史版本与变更记录。
- 分析层：关联漏洞库、许可证策略、服务目录，计算风险分与分级结果。
- 展示与流程层：提供查询、报表、审批入口，并与CI/CD、工单系统集成，实现“发现—登记—评估—处置”闭环。
五、盘点结果示例与判断依据
假设某服务扫描后发现：log4j-core 2.14.1 被3个应用使用，许可证为Apache-2.0，供应商为Apache，存在已知高危漏洞；某广告SDK 4.2.0 被1个客户端应用使用，涉及设备标识采集，供应商维护状态一般。根据分级标准，前者应定为L1或L2并立即进入漏洞修复流程，后者应定为L2并触发隐私合规评估。判断依据不是“感觉危险”，而是数据敏感度、影响范围、漏洞状态和可替代性四个维度的组合。
盘点不是一次性项目，而是持续运营。每次构建、每次引入新SDK、每次漏洞披露，都应触发资产库更新和分级复核。只有把发现、建模、分级、工具链串成闭环，SDK治理才有可靠的数据基础。