DORA 第三方风险：移动端 SDK 治理

如果您一直在关注本系列，那么现在您已经拥有：

• 一个界定移动风险面的范围（第 1 篇：理解面向移动团队的 DORA 合规）
• 为每个构建版本给出明确裁决的发布级控制（第 2 篇：面向移动发布的 DORA 合规）
• 与真实移动故障模式相关联的韧性证据（第 3 篇：DORA 移动韧性演练）

剩下的领域是第三方风险。

移动应用在发布时内嵌了 SDK，并在运行时依赖外部提供商。在 DORA 之下，这种暴露仍然是您的责任，并且必须在发布级别加以治理。这一点在移动项目中常常被忽视，因为“供应商风险”往往被当作纸面文书来对待，而不是被视为直接落入二进制文件和客户旅程中的东西。

1）为什么移动端第三方风险有所不同

从结构上看，移动应用是一个打包好的制品，类似于 Docker 镜像或 Java WAR 包。您将自己的代码与第三方库捆绑在一起，并发布一个特定的版本。这部分并不独特。

独特之处在于您发布之后会发生什么。后端团队通常可以在自己运营的基础设施上集中打补丁并重新部署。而移动团队通过应用商店将应用发布到用户设备上，补丁的采用取决于商店处理、分阶段推送决策、设备限制以及用户更新。这意味着较旧的版本会在野外持续活跃，往往长达数周甚至更久。

有两种不同的风险类型需要您加以治理。

内嵌 SDK
这些 SDK 随二进制文件一起发布，并以应用的权限运行。当某个 SDK 存在漏洞、策略问题或破坏性变更时，修复是以发布为形态的。您需要通过发布一个新的应用版本来修复它，然后等待它被采用。实际结果是，在多个同时运行的应用版本之间会出现长时间的暴露。

运行时提供商
诸如身份认证、OTP、推送、反欺诈和支付等外部服务，可能会出现性能下降、部分失败，或在不同环境中表现不一致。这种不稳定会直接体现在真实设备和真实网络上的关键移动旅程中。一旦失败，用户会立刻察觉。

由此带来的治理含义简单而严格：移动端的第三方风险必须以发布为范围、与运行时相关，并以证据驱动。

2）SDK 治理模型（以发布为范围）

目标是控制每个发布版本中允许发布的第三方代码，并且其方式日后能够被证明。该模型从清单开始，然后让变更变得可见，接着附上决策记录，使发布裁决站得住脚。

从每个发布版本的 SDK 清单开始。把它当作一个基线，而不是一次性报告：对于每一条发布记录，您都应该能够展示 SDK 名称、确切版本、来源/出处、功能角色，以及（在您掌握的情况下）风险说明或分类。该清单成为审批、禁用、补丁 SLA 和审计检索的锚点。

然后，要求每个发布版本都有一份差异。对于每个新发布版本，您都应该能够说明与上一个获批发布版本相比，新增了哪些 SDK、哪些版本发生了变化、移除了哪些内容。这正是将“我们认为没有任何变化”转变为“我们能展示发生了什么变化”的关键。

一旦您能够看到变化，就能够加以控制。定义审批规则，使新增 SDK 和重大升级需要明确的审查决策，而常规的补丁升级只要仍处于您获批的版本策略之内，就可以走更轻量的路径。与此同时，维护一份禁用列表，列出已弃用的 SDK、存在漏洞的版本或不合规的提供商，使已知风险无法通过依赖漂移重新进入应用。

最后，定义与您的风险策略相一致的补丁 SLA，并针对每个 SDK 漏洞衡量修复耗时（time-to-patch）。关键不在于尽善尽美；关键在于当打补丁被延迟时，您能够展示一个有明确时限的决策，而不是一个失控的积压。

字段	说明
SDK 名称	库或供应商名称
版本	构建版本中包含的确切版本
来源	供应商、仓库或出处
角色	分析、认证、支付等
风险说明	已知风险、分类或依据

3）面向移动端的 SBOM 式证据

DORA 并不要求移动端提供一份完美的 SBOM。它要求依赖具有可见性，且该可见性针对特定发布版本、站得住脚，并与运营治理相关联。

面向移动端的最小可行 SBOM，是该发布版本的 SDK 清单（名称 + 版本），加上您的构建工具链所能提供的任何依赖引用，再加上与该确切发布版本关联的漏洞背景信息。要求在于它以版本为范围，并与发布记录相关联，这样您就能回答“版本 X 中存在哪些依赖？”，而无需从源代码管理、旧的 CI 日志或口口相传的经验中重新拼凑。

4）发布级控制

要使第三方治理具备可操作性，就要将其表达为能够产生明确结果的发布控制。您的目标不是制造更多文档；而是产出一个在审视下依然成立的发布裁决。

一个可行的最低要求是：确保每个发布版本都有一份 SDK 清单、一份相对于上一个发布版本的 SDK 差异、对新增 SDK 和重大升级的明确审批或例外，以及一项检查来确认被禁用的 SDK 和版本不存在。每个发布版本还应展示一个漏洞态势，即要么处于 SLA 之内，要么由一个有明确时限的例外所覆盖。在运行时方面，该发布版本应链接到关键旅程的提供商依赖映射，并引用针对这些旅程所定义的性能下降与回退决策。

如果您已经拥有一条第 2 篇：面向移动发布的 DORA 合规的裁决流水线，那么这些就成为进入同一裁决的第三方输入。发布记录仍然是决策及其证据链接所在的唯一位置。

5）可供审计的证据包（按发布版本）

至此，证据在发布级别汇聚。证据包并不是“您拥有的一切”，而是解释该发布版本在部署时为何可被接受的最小制品集合。

一个发布证据包应包含：

• 发布标识（应用 ID、版本、构建引用、制品指纹）
• SDK 清单与差异
• 审批与例外
• 按关键旅程划分的提供商映射
• 性能下降与回退定义
• 来自第 2 篇：面向移动发布的 DORA 合规的控制结果
• 来自第 3 篇：DORA 移动韧性演练的韧性证据

“我们有证据”与“我们可供审计”之间的差别在于检索，因此请维护一个简单的索引，按发布版本组织，并指向证据包的内容。

为避免例外变成缺口，请对例外记录进行标准化。它应标明范围（SDK 或提供商）、受影响的一个或多个发布版本、依据、负责的风险负责人、补偿性控制、到期或复审日期，以及审批时间戳。这将“我们无法打补丁”转变为“我们做出了一个有明确时限、有归属和控制的决策”。

如此一来，留存就变得简单明了：按照您的内部政策和监管政策，保留发布记录、证据包和索引。重要的特性在于，证据始终以版本为范围、建立索引，并可按需检索。

6）面向管理层的报告（关注趋势）

在管理层层面，目标是趋势的可见性，而不是对每个发布版本重新进行争论。三个指标往往效果很好。例外的老化情况显示风险决策是在被重新审视，还是正在变成永久性的。SDK 漏洞的修复耗时显示您的移动供应链是否具有响应能力。每个发布版本的 SDK 变更率显示依赖的流动情况，它与审查工作量和意外风险高度相关。

从小处着手，再逐步扩展

在不打断发布节奏的前提下循序渐进地实施。先从 SDK 清单和按发布版本的差异开始，因为可见性能带来掌控力。然后为新增 SDK 和重大升级添加审批，接着是禁用列表的强制执行，以及带有明确时限例外的补丁 SLA 跟踪。

一旦 SDK 治理趋于稳定，就按关键旅程映射提供商依赖，并记录回退决策。最后，将证据包索引和留存制度化，使检索成为常规工作，而不是一个特殊项目。