面向移动团队的 DORA 合规：理解范围以及您需要做什么

DORA 合规系列导读：

DORA 法规（《数字运营韧性法案》）给移动团队提出了一个合理的问题：这对 iOS 和 Android 的交付究竟意味着什么？

本系列共四篇，从实践角度回答这个问题。不深挖法规条文，不谈空洞理论，只提供一种以移动为先的 DORA 合规方法，适用于移动团队、AppSec 团队以及负责监督他们的管理者。

• 第 1 篇：理解范围以及您真正需要做什么 （本文）
• 第 2 篇：移动版本发布最简单的基线、结论与例外模型
• 第 3 篇：面向 BFSI 移动旅程的最简韧性演练库
• 第 4 篇：第三方风险、SDK 治理与可供审计的证据包
  
  

---

如果您正在构建或保护一款银行、金融服务和保险（BFSI）领域的移动应用，那么您早已领教过合规与现代工程相遇时的“乐趣”。您的应用同时是一个产品、一道安全边界、一块客服问题的磁铁，也是一个依赖收集器。

现在，DORA 法规登场了，紧随其后的是 DORA 合规这个说法，通常还附带一个截止日期和一张电子表格。

本文是一份以移动为先的指南，力求务实。我们将界定一个严格的移动范围，把 DORA 应用到移动场景中，并最终落到一个对移动团队和决策者都行之有效的简单运营模式上。

我们会让一切都围绕移动团队始终关注的那件事展开：版本发布。

那么，为什么这件事从一开始就让人感到痛苦呢？

为什么 DORA 让移动团队和 AppSec 团队感到痛苦

DORA 之所以常常让人感到痛苦，是因为它以合规问题的形态出现，而移动工作却是以版本发布为单位的。移动团队考虑的是应用版本、构建号、发布计划、关键旅程和事件处置手册。合规要求往往以“证明 X”的形式出现，却没有说清楚 X 对 iOS 和 Android 而言意味着什么。

事情之所以变得复杂，还因为移动风险很少只存在于移动代码中。一个移动旅程可能因身份服务、OTP 延迟、推送送达、后端 API、欺诈检测、远程配置错误或第三方提供商故障而失败。当一项要求写着“确保韧性”时，移动团队首先会问：“到底是什么的韧性？又如何衡量？”

减轻痛苦最简单的方法不是对抗 DORA，而是把 DORA 法规转化为一个您真正能够负责的移动范围，然后为每个版本生成可重复的证据，让 DORA 合规成为例行工作。

好，那么用通俗的话来说，DORA 到底是什么？我们不打算把这变成一场法规读书会。

用通俗语言解读 DORA，并转化为移动领域的现实

从宏观层面看，DORA 法规推动组织实现两个结果：

1. 让数字服务安全地持续运行，包括在中断期间。
2. 用可重复、可验证的证据证明这种能力。

对移动团队而言，“数字服务”指的是端到端的移动体验，而不仅仅是应用的二进制文件。您的应用依赖于身份与身份验证、后端 API、OTP 和推送通知、欺诈与风险系统、支付服务，以及随应用一起发布的第三方 SDK。

以移动为先的 DORA 解读如下：

• ICT 风险管理：定义移动版本发布控制措施的基线，并明确负责人。
• 事件准备：要求进行区分版本的影响评估、明确时间线，并准备一个无需费尽周折即可整理出的证据包。
• 运营韧性测试：针对关键移动旅程开展演练，而不只是一次性测试。
• ICT 第三方风险：涵盖对嵌入式 SDK 以及可能破坏关键旅程的运行时提供商的治理。
• 持续改进：建立一个闭环，让事件和演练推动控制措施、监控和运行手册的更新。

如果您能始终如一地做到这些，您就不“只是”在处理文书工作，而是在构建一个支撑 DORA 合规的移动运营模式。

用一页纸界定“移动 DORA 范围”（哪些在内，哪些在外）

明确范围是减少合规反复折腾的最快方法。以下是属于移动团队的 DORA 合规工作的一个严格而务实的范围。

属于移动团队的范围

• 您发布的移动版本产物
  iOS IPA 以及 Android AAB 或 APK，与特定的版本号和构建号相对应。
• 发布流程证据
  构建来源、签名、审批，以及某个候选版本运行了哪些检查的记录。
• 嵌入的第三方 SDK 和库
  应用中包含什么、自上一个版本以来发生了哪些变化，以及由谁批准。
• 影响关键移动旅程的运行时依赖
  身份与身份验证、后端 API、OTP 和推送、欺诈与风险系统、支付、远程配置以及功能开关。
• 关键旅程
  登录、升级身份验证、账户恢复、支付与转账，以及（如果您的应用包含）新用户注册流程。

既然范围已经明确，我们就可以提出那个让 DORA 对移动团队保持务实的问题。

让 DORA 合规保持务实的单一版本级问题

要回答“这个移动应用版本是否符合我们与 DORA 对齐的应用安全和韧性控制措施”这个问题，您的回答必须：

• 具体：针对特定的 iOS 或 Android 版本和构建。
• 可重复：每个版本都要回答，而不是只在合规部门询问时才回答。
• 可执行：能够对应到具体的检查和负责人。
• 可审查：风险部门和管理层每次都能评估形式相同的证据。

这个问题并没有把 DORA 法规简化为“只关乎移动”。它只是界定了移动团队能够可信地负责的内容：针对移动版本产物和移动旅程的版本级保障。

要回答这个问题，又不让发布日变成一场仪式，您需要一个最小化的运营模式。

最小化运营模式（发布记录、发布结论、证据包）

要让这个版本级问题可以被回答，您需要三个基本构件。先保持轻量，再逐步实现自动化。

1) 发布记录

这是该版本的“索引卡”，它把版本产物、证据和决策联系在一起。

最少需要以下字段：

• 应用标识符（bundle id 或包名）
• 平台（iOS 或 Android）
• 版本号和构建号
• 产物标识符或指纹（哈希值或唯一的构建 ID）
• 源代码引用（代码仓库和提交 SHA）
• 流水线运行 ID
• 发布负责人和日期

如果无法把证据与特定产物关联起来，日后您就无法可靠地证明任何事情。这很枯燥，但这是一种好的枯燥。

2) 发布结论

采用一个既符合实际情况又支持治理的结论模型：

• PASS
• FAIL
• PASS_WITH_EXCEPTIONS

只要处于受控状态，PASS_WITH_EXCEPTIONS 就是有效的。这意味着要有负责人、到期日期、补偿性控制措施和修复计划。如果例外永不过期，它们就会成为真正的基线。

3) 证据包

证据包让您的发布结论站得住脚，也让您的 DORA 合规陈述令人信服。

证据包应当回答：

• 发布了什么？
• 运行了哪些检查，发现了什么？
• 如果存在风险，是如何处理的，由谁批准？

每个版本最少应保留的证据：

• 构建来源和签名证明
• 与确切产物相对应的安全测试输出
• 包含严重程度和类别的发现列表
• 与上一个已批准版本相比的差异，即发生了哪些变化
• 该版本的 SDK 清单，以及自上一个版本以来的变化
• 证明关键旅程的韧性演练和运行手册处于最新状态
• 例外审批及其到期日期（如有）

对移动团队而言，好处在于这项工作变得可重复。对决策者而言，好处在于审查变得一致且可审计。

如果您在想“这听起来还是要花功夫”，这很合理。让我们来定义 30 天内“做好”是什么样子，好让它始终切实可行。

制造不必要工作的常见陷阱，以及更简单的替代方案

陷阱 1：“一次扫描就能说明我们符合 DORA。”

扫描是很有价值的证据，但 DORA 合规的范围远比任何单一输出都要广。

更简单的替代方案：让结论限定在版本范围内。把扫描作为输入发布结论和证据包的证据。

陷阱 2：范围不断蔓延，直到移动团队负责一切

当职责归属不清时，移动团队最终要去协调半个组织。

更简单的替代方案：保持严格的移动范围。负责移动版本发布、关键移动旅程、嵌入式 SDK 治理和版本级证据。与身份、平台和提供商的负责人合作处理上游控制措施。

陷阱 3：无法提供证据的控制措施

如果一项控制措施无法与产物、报告、工单或日志关联起来，它就会成为反复争论的话题。

更简单的替代方案：不断改写控制措施，直到证据一目了然。如果您无法为它提供证据，它就还算不上一项控制措施。

陷阱 4：永不过期的例外

永久性的例外会变成永久性的风险。

更简单的替代方案：每个例外都需要负责人、到期日期、补偿性控制措施和修复计划。跟踪例外是否按期到期。

陷阱 5：测试组件而不是旅程

组件测试很有用，但客户体验到的是旅程。

更简单的替代方案：定义关键旅程，并针对会破坏这些旅程的故障模式开展演练，例如身份服务降级、OTP 延迟、推送中断和提供商故障。

如果您只能从本文中记住一件事，那就是：DORA 不必成为一个游离于移动版本发布周期之外的平行“合规项目”。当您把范围限定在移动领域、把版本发布作为治理单元，并在发布过程中生成证据时，DORA 法规的要求就会变得可控，DORA 合规也会变得可重复。

在下一篇文章中，我们将让这一切更加具体。我们会定义一个简单的与 DORA 对齐的移动版本发布控制基线，展示如何将其转化为清晰的 PASS、FAIL、PASS_WITH_EXCEPTIONS 结论，并分享在不拖慢交付的前提下处理例外的最简单方法。

Ostorlab 在这一移动 DORA 范围中的定位

扫描是一项证据输入，而不是 DORA 结论（陷阱 1）。以下说明 Ostorlab 能为您的移动版本生成证据包中的哪些部分、它需要您提供什么，以及哪些工作仍由您的团队负责。

您能为证据包获得什么。

• 与构建版本相对应的安全测试输出：按构建版本和按应用商店版本提供扫描结果，每个发现都被评定为严重、高危、中危或低危，潜在发现则单独列出。Mobile SAST 直接分析 APK、AAB 或 IPA，无需源代码；Mobile DAST 运行应用并捕获流量、堆栈跟踪和屏幕截图。
• 每个版本的 SDK 清单：每个版本中的 SDK 和原生库，包括其版本及其在应用包中的位置，并与已知漏洞对应，在版本之间持续跟踪。
• 对登录后关键旅程的测试：Ostorlab 使用您的测试账户登录，完成短信、电子邮件或 TOTP 一次性验证码验证，并测试登录、令牌刷新、会话失效和 MFA 强制执行，包括升级身份验证流程。针对应用及其 API 的 AI 智能体渗透测试会为每个 AI 智能体发现附上一个可重放的有效漏洞利用。
• 修复证明：发现会在平台中或在 Jira 和 ServiceNow 中作为工单进行跟踪，修复后的重新测试会确认问题是否已解决。

您需要提供什么。

• 版本产物（APK、AAB 或 IPA），或来自应用商店或 TestFlight 的应用。
• 接入 CI/CD 流水线的扫描，确保每个构建版本都经过扫描；在没有发布版本的周次中，定时运行的流水线可保持每周一次的节奏。
• 测试账户和一次性验证码的接收方式，以便对登录、支付和账户变更进行测试，而不仅仅是登录界面。

哪些工作仍由您的团队负责。 Ostorlab 覆盖移动应用及其背后的 API。发布结论、例外审批、业务功能分类以及您的测试计划仍由您负责。Ostorlab 不执行威胁导向的渗透测试（TLPT），也不能替代它：它帮助您在进入 TLPT 之前修复已知的应用和 API 问题，并在之后重新测试修复计划中的应用和 API 项。超出应用层的要求，例如网络、物理安全、备份和事件管理，仍由其他工具和团队负责。

证据。

• 面向移动银行应用的 DORA 韧性测试将 DORA 的每项测试要求与 Ostorlab 所做的工作以及仍由您负责的工作一一对应。
• Bumble 案例研究展示了发布关卡的实际运作：在修复得到确认之前，存在高危和严重发现的版本会被阻止发布。
• 用于您的 ICT 第三方风险审查：Ostorlab 拥有一份 SOC 2 Type II 报告（Security 准则），覆盖期间为 2024 年 11 月 18 日至 2025 年 4 月 18 日，当前期间的审计正在进行中。在 Enterprise 计划中，您可以选择欧盟数据驻留，或在本地部署运行扫描。

下一步。 建立基线：对每个面向客户的应用，从应用商店获取并执行一次免费扫描，然后预约演示，规划覆盖各个版本的测试。

下一篇：面向移动版本发布的 DORA 合规：最简单的基线、结论与例外模型 如果您负责移动版本发布就绪、AppSec 关卡或风险签核，这篇文章将让 DORA 从“我们应该做点什么”变成“这就是我们发布版本的具体方式”。