移动应用发布的 DORA 合规：最简基线、裁决与例外模型

如果您读过本系列的第一篇文章：面向移动团队的 DORA 合规：理解范围与需要做的事，那么您已经打好了基础。

1/ 您了解自己的移动范围，并理解为何发布是最自然的治理单元；

2/ 您已经掌握了那个能让 DORA 合规保持务实的关键问题：这个移动应用发布是否符合我们与 DORA 对齐的应用安全与韧性控制？

现在，到了让这个问题能够以可重复、可审计的方式得到回答的部分。

本文讲的是移动应用发布的 DORA 合规机制。我们将为移动端定义一个最小控制基线，引入一个简单的裁决模型，并介绍如何处理例外，而不至于让每一次发布都变成一场治理谈判。

让我们先从为何这是围绕发布展开的工作、而非泛泛的合规工作说起。

为何发布是移动端 DORA 合规最务实的单元

当您试图提出“我们的应用符合 DORA 合规”这样一个全局性论断时，移动端合规就会变得很难。这种论断把组织治理、第三方监督、事件流程和技术控制混为一句话，而从移动团队的视角看，这几乎无法干净利落地提供证据。

发布是更好的单元，因为这本就是移动端工作发生的方式。每一次 iOS 和 Android 发布都代表一次离散的变更，风险随之改变。证据可以在发布当时采集，而不必在日后有人发来审计请求时再去重建。

当您把发布作为 DORA 合规的单元时，会发生三件事：

• 证据作为交付的一部分被自然地采集。
• 风险决策是显式作出的，而非想当然。
• 合规叙事在一次又一次发布中保持一致。

接下来，我们将定义一个既足够精简、便于维护，又足够有力、切实有用的基线。

移动应用发布的 DORA 合规基线

让 DORA 合规对移动团队落地的最简单方式，就是定义一个基线。基线不过是一份控制清单，每一次发布在交付前都必须满足其中的每一项。最多保持在 10 到 20 项控制。再多就会从治理工具沦为维护负担。

一项好的控制具有三个特性。它是二元或接近二元的，也就是说您可以给出通过或不通过。它与证据挂钩，也就是说您可以指向某个工件、报告或工单。它有一个负责人，也就是说当它不通过时有人负责。

在深入之前先提醒一句。如果您放任不管，这部分可能变得很复杂。请保持简单。如果一项控制无法提供证据，那它还算不上一项控制。

以下五个类别涵盖了移动范围内 DORA 合规的大部分内容。

1) 发布完整性与可追溯性

这个类别回答的是：您是否确切知道交付了什么，并能在日后加以证明。在实践中，这意味着每一个发布工件都以版本号、构建号和指纹进行唯一标识，并由经批准的流水线签名和产出。它还意味着您的安全检查运行在确切的候选发布工件上，而非某个开发者构建版本或近似的预发布版本，并且您有一份溯源记录，将该工件关联回某个提交、仓库和流水线运行。最后，支撑性证据得以保留，以便日后无需依赖任何人的记忆即可审查。

这是枯燥但至关重要的类别，因为如果您无法识别工件，其他一切都无从归因。

2) 漏洞与暴露阈值

这个类别回答的是：这次发布是否在我们既定的风险容忍范围之内？

能让团队免于麻烦的控制：

• 发布中没有严重（Critical）级别的发现。
• 在移动端关键类别中没有高危（High）级别的发现，这些类别通常包括身份验证与会话管理、密码学、敏感数据存储、传输安全，以及不安全的配置。
• 与上一个获批发布相比，没有新增的严重或高危回归问题。
• 对于不阻断发布的发现，存在明确的修复预期，以免风险在无声中累积。

这里的关键在于，在应用阈值之前先把阈值定义好。“我们看到了自然就知道”不是一项控制。

3) 第三方 SDK 治理

这个类别回答的是：我们是否知道二进制文件里有什么，以及我们是否掌控它如何变化？

让 SDK 风险变得可管理的控制：

• 本次发布存在一份 SDK 清单，列出每一个内嵌的 SDK 和库。
• 存在一份差异记录，显示自上一个获批发布以来发生了哪些变化。
• 新增 SDK 或大版本升级需要明确的批准和指定的负责人。
• 被禁用的 SDK 类别或已知存在漏洞的 SDK 版本被阻止交付。
• 存在一套能够快速响应严重 SDK 安全公告的流程，并有明确的打补丁预期。

移动端具有独特的第三方风险特征，因为依赖是随应用一起交付的。一个 SDK 可能在您自己的代码毫无改动的情况下，采集意料之外的数据、破坏某条用户流程，或引入漏洞。正是在这个类别，DORA 合规变得非常具有移动端特性。

4) 关键用户流程的韧性就绪度

这个类别回答的是：我们是否测试过那些对客户最为重要的故障模式？

能让“韧性”不至于流于空泛的控制：

• 为应用声明关键用户流程，例如登录、二次强身份验证（step-up）、账户恢复和支付。
• 为每条用户流程建立依赖关系图，涵盖身份、OTP 与推送、API、反欺诈、支付和远程配置。
• 为高风险功能建立并已测试回滚计划、紧急开关（kill switch）和功能开关（feature flag）护栏。
• 韧性演练证据已附上并链接到发布记录中。

正是这个类别把“我们是安全的”和“我们是有韧性的”区分开来。安全与韧性相关，但并不是一回事。

5) 事件响应就绪度

这个类别回答的是：万一本次发布出了问题，您能否快速、干净利落地响应。在实践中，这意味着您的遥测数据支持按版本进行分析，从而能够识别哪些应用版本受到影响，以及在实施缓解措施后影响如何变化。它还意味着您为移动端安全事件（包括欺诈和账户接管信号）制定了清晰的事件严重程度判定标准，并有一份证据包模板，可以在无需人工取证的情况下快速填写。最后，您需要一套决策记录流程，记录决定了什么、由谁决定、基于什么依据，从而使事件叙事保持一致、可供审查。事件响应就绪度往往是团队最后才建立的类别，但当问题真正发生时，它却是最重要的那一个。

一旦有了基线，您还需要一种一致的方式来表达每次发布评审的结果。

DORA 合规发布裁决模型

一旦有了基线，每一个候选发布都应产生三种结果之一。

PASS（通过）

所有控制均已满足。证据完整并链接到发布记录。该发布可以继续进行。

FAIL（不通过）

一项或多项阻断性控制未被满足。在阻断项得到解决或通过例外正式处理之前，该发布不会交付。

PASS_WITH_EXCEPTIONS（附例外通过）

该发布仅因一项或多项控制通过正式批准的例外被豁免而满足基线。这是一种受治理的结果，而不是走捷径。

三状态模型比二元模型更诚实。在移动端 BFSI 领域，有时您需要为了应对更高优先级的风险而交付，此时一个附带补偿性控制的正式例外，比假装一切都好要负责得多。

例外正是合规项目要么保持自律、要么慢慢滑向“我们以后再修”境地的分水岭。

如何在不拖慢一切的前提下处理例外

例外之所以名声不佳，是因为它们往往既不正式又永久存在。一个治理得当的例外其实是一个有用的工具。它让您能够显式地做出一次受控的权衡，而不是任由风险悄然累积。

一个好的例外需要五样东西：

• 一个 ID，以便在各次评审之间进行追踪。
• 一个负责人，负责解决它。
• 一段风险陈述，用平实的语言解释风险是什么，以及为何目前可以接受。
• 补偿性控制，在例外生效期间降低其实际影响。
• 一个到期时间，以强制后续跟进。如果它不会到期，那它就不是例外，而是一次策略变更。

治理规则很简单。只有当上述五个要素齐备并由合适的人员批准（通常是安全与风险共同批准）时，PASS_WITH_EXCEPTIONS 才是有效的。

将例外作为一项指标来追踪。如果例外数量在增长而到期合规率偏低，那么您的基线就不是在被执行，而是在被绕过。

现在我们把这一切重新关联回发布记录，因为正是它让审计和评审变得轻松得多。

最小发布记录字段（让审计变得容易）

发布记录将裁决与证据关联起来，使整个模型可供审计。以下是每一份发布记录都应包含的最小字段。

发布身份

• 应用标识符（bundle id 或包名）
• 平台（iOS 或 Android）
• 版本号与构建号
• 工件指纹或唯一构建 ID
• 源引用（仓库、提交 SHA、流水线运行 ID）
• 发布负责人

裁决

• PASS、FAIL 或 PASS_WITH_EXCEPTIONS
• 控制汇总，哪些通过、哪些不通过
• 若为 FAIL，列出阻断项、发现或问题 ID、负责人和修复目标
• 若为 PASS_WITH_EXCEPTIONS，列出例外清单、例外 ID、被豁免的控制、到期时间、批准人

证据链接

• 关联到工件的安全测试报告
• 带有严重程度和类别的发现导出
• SDK 清单与差异
• 关键用户流程的演练证据和操作手册链接
• 审批记录和例外登记簿条目

如果您具备这些字段，审计人员日后便可审查某次发布决策，而无需让团队从头重建一切。这就是其实际价值所在。

最后一块，推广落地。目标是让这一切感觉像是正常的交付，而非一项新的仪式。

如何在不打断发布节奏的前提下推广落地

团队最大的错误就是试图一次性强制执行所有内容。那会制造阻断项、拖慢发布，并让基线感觉像是障碍而非工具。

更好的做法是从窄处起步，逐步扩展。

从一道硬性关口开始

挑选最重要的单项控制，并将其作为阻断项强制执行。一个不错的首选是“没有严重级别的发现”。其余一切都可以度量，但在最初几次发布中不作阻断。

逐步增加控制

随着团队对该模型越来越熟悉，每次增加一两项控制。目标是让基线感觉像是交付中正常的一部分，而非一项独立的合规工作。

尽早自动化证据采集

您越早自动化证据生成，这个模型就越不费劲。先从关联到工件的扫描报告开始，然后加入 SDK 差异，再加入演练和操作手册检查。

从第一天起就让例外可见

即使您起初很少使用例外，也要从一开始就让它们可追踪、有时限。在例外非正式地存在了数月之后，再给它们加上治理要难得多。

结语

控制基线不必完美才有用。它需要的是一致、有证据支撑并得到执行。当每一次 iOS、Android 或 HarmonyOS 发布都产生一个裁决和一份关联的证据包时，DORA 合规便不再是每个季度的手忙脚乱，而开始成为移动端交付方式的自然产物。

在下一篇文章中，我们将从发布控制转向运营韧性。我们将介绍面向 BFSI 移动用户流程的最简演练库、每项演练应产出什么证据，以及如何在演练结果与发布控制之间形成闭环。

下一篇：DORA 下的移动运营韧性：面向 BFSI 用户流程的最简演练库