面向您的客户所使用的应用的 DORA 测试。

1. 01

   DORA，第 8 条

   了解哪些应用和组件支撑关键职能

   文本的内容

   识别、分类并记录所有由 ICT 支持的业务职能及其背后的信息资产和 ICT 资产，包括其依赖关系以及依赖 ICT 第三方服务提供商的流程。至少每年审查一次分类，并持续评估网络威胁和 ICT 漏洞。

   来源：DORA，第 8 条

   对您的移动应用意味着什么

   客户用于登录、支付和管理账户的移动银行应用通常会支撑关键或重要职能，其调用的 API 和嵌入的 SDK 也是如此。这一分类决定了您必须以怎样的频率和深度开展测试。

   Ostorlab 如何提供帮助

   Ostorlab 显示您应用每个版本包含的内容：第三方 SDK 和原生库及其版本和在应用包中的位置，应用及其 SDK 通过网络与后端交换的内容，以及应用收集和共享的个人数据。

   仍由您负责的部分

   业务职能分类、清单本身及其年度审查。

2. 02

   授权条例 (EU) 2024/1774，第 10 条

   至少每周自动扫描关键资产

   文本的内容

   漏洞管理程序必须包括自动化漏洞扫描和评估，对于支撑关键或重要职能的 ICT 资产，频率至少为每周一次。您还必须跟踪第三方和开源库，按关键程度确定补丁的优先顺序，验证修复，并记录每个检测到的漏洞，直至其得到解决。

   来源：授权条例 (EU) 2024/1774，第 10 条

   对您的移动应用意味着什么

   您的移动应用及其 API 需要一个即使在没有发布的周次也保持不变的自动化扫描频率，并需要记录每项发现从检测到修复的全过程。

   Ostorlab 如何提供帮助

   从您的 CI/CD 流水线对每个构建运行自动扫描，并在无需手动触发的情况下监控商店版本。通过定时运行流水线，可在两次发布之间保持每周的扫描频率。发现会被评为严重、高、中或低风险，以工单形式在平台中或 Jira 和 ServiceNow 中跟踪，并在修复发布后进行复测。

   仍由您负责的部分

   补丁期限和升级处理程序，以及对其余 ICT 资产的扫描。

3. 03

   授权条例 (EU) 2024/1774，第 16 条

   在投入生产前对代码进行静态和动态测试

   文本的内容

   在使用前和维护后，按照关键程度对每个 ICT 系统进行测试和审批。测试包括涵盖静态和动态测试的源代码审查、针对暴露于互联网的系统和应用的安全测试，以及针对所发现漏洞的行动计划。在可行的情况下，第三方和开源代码在部署到生产环境之前接受分析和测试。

   来源：授权条例 (EU) 2024/1774，第 16 条

   对您的移动应用意味着什么

   移动银行应用属于暴露于互联网的应用。每个版本在上架商店之前都应通过静态和动态安全测试，而其中的 SDK 属于第三方代码，同样受这一规则约束。

   Ostorlab 如何提供帮助

   Mobile SAST 直接分析 APK、AAB 或 IPA，无需源代码，并对嵌入的 SDK 进行污点分析。Mobile DAST 运行应用，保持登录会话，并捕获流量、堆栈跟踪和截图。SCA 通过指纹识别基于清单文件的扫描器可能遗漏的静态编译库。

   仍由您负责的部分

   应用之外的源代码审查、发布审批环节，以及行动计划的归属。

4. 04

   DORA，第 9 条第 4 款 (d) 项；授权条例 (EU) 2024/1774，第 21 条

   强认证，像其他控制措施一样接受测试

   文本的内容

   基于相关标准，实施强认证机制的政策和协议。RTS 要求认证方法与每项 ICT 资产的分类和风险状况相称，并要求对支撑关键或重要职能或可公开访问的资产采用强认证。

   来源：DORA，第 9 条第 4 款 (d) 项；授权条例 (EU) 2024/1774，第 21 条

   对您的移动应用意味着什么

   登录、一次性验证码和增强验证都属于认证控制，后端执行这些控制的方式存在缺陷，就是这些控制本身的缺陷。它们应纳入您测试计划的范围。

   Ostorlab 如何提供帮助

   Ostorlab 使用您的测试账户登录，完成短信、电子邮件或 TOTP 一次性验证码，并测试登录和注销、令牌刷新、超时、会话失效以及 MFA 强制执行，包括增强验证流程。

   仍由您负责的部分

   员工和特权访问、身份生命周期管理，以及认证标准的选择。

5. 05

   DORA，第 24 条和第 25 条

   实施基于风险的测试计划，并开展年度测试

   文本的内容

   作为 ICT 风险管理框架的一部分，建立、维护并审查数字运营韧性测试计划。该计划规定适当的测试，例如漏洞评估和扫描、开源分析、在可行时开展的源代码审查、基于场景的测试、端到端测试和渗透测试，并至少每年对所有支撑关键或重要职能的 ICT 系统和应用进行测试。

   来源：DORA，第 24 条和第 25 条

   对您的移动应用意味着什么

   您的移动应用需要在计划中有明确的位置：运行哪些测试、多久一次、针对哪个版本。仅靠一年一次的渗透测试，两次测试之间的每次发布都未经测试。

   Ostorlab 如何提供帮助

   快速扫描通常在 1 到 5 分钟内完成，完整扫描需要 15 到 45 分钟，因此适合每次发布。AI 智能体渗透测试更加深入，通常需要几个小时，AI 智能体的每个发现都附有可重放的有效漏洞利用，适用于关键变更和您的定期深度测试。

   仍由您负责的部分

   计划文件、其基于风险的设计，以及应用层以外的测试，例如网络、物理和性能测试。

6. 06

   DORA，第 24 条第 4 款和第 5 款

   由独立方测试，并证明每项修复

   文本的内容

   测试必须由独立方执行，可以是内部或外部人员，须具备充足的资源且不存在利益冲突。您必须对测试揭示的每个问题进行优先级排序、分类和修复，并建立内部验证方法，确认每个薄弱环节都已得到彻底解决。

   来源：DORA，第 24 条第 4 款和第 5 款

   对您的移动应用意味着什么

   开发应用的团队不应是唯一测试它的团队，而关闭的工单并不是证据：您需要证明修复有效的证据。

   Ostorlab 如何提供帮助

   由您的安全团队或第二道防线团队执行测试并掌握结果。每项发现都附有风险等级、复现步骤、请求和响应日志以及截图，复测会确认底层问题是否已解决。

   仍由您负责的部分

   确定您组织中谁可视为独立方，以及验证的签字确认。

7. 07

   DORA，第 26 条和第 27 条；授权条例 (EU) 2025/1190

   若被认定，至少每 3 年开展一次 TLPT

   文本的内容

   被其主管当局认定的实体必须至少每 3 年开展一次威胁主导的渗透测试，对象为支撑关键或重要职能的实时生产系统。测试人员必须满足第 27 条的要求，重要信贷机构必须使用外部测试人员。测试结束后，修复计划和相关文件提交给 TLPT 主管机构。

   来源：DORA，第 26 条和第 27 条；授权条例 (EU) 2025/1190

   对您的移动应用意味着什么

   TLPT 是一项由情报主导、持续数月的红队演练（见下方各阶段）。常规测试本可发现的应用和 API 薄弱环节会占用红队的时间，并最终进入修复计划。

   Ostorlab 如何提供帮助

   Ostorlab 不执行 TLPT，也不取代 TLPT。它帮助您在开展 TLPT 前修复已知的应用和 API 问题，并在之后复测修复计划中的应用和 API 事项。

   仍由您负责的部分

   TLPT 本身：控制团队、威胁情报提供方、红队测试人员，以及与 TLPT 主管机构的沟通。

8. 08

   DORA，第 28 至 30 条

   将测试供应商作为 ICT 第三方进行管理

   文本的内容

   金融实体在使用 ICT 第三方服务提供商时仍须对合规承担全部责任，并保存有关这些安排的信息登记册。合同必须涵盖数据保护；对于支撑关键或重要职能的服务，还必须涵盖不受限制的访问、检查和审计权，以及服务提供商对 TLPT 的参与。

   来源：DORA，第 28 至 30 条

   对您的移动应用意味着什么

   接收您的应用二进制文件和测试凭据的 SaaS 测试平台，属于您的第三方风险流程将要审查的供应商。

   Ostorlab 如何提供帮助

   Ostorlab 已通过 SOC 2 Type II 审计。企业版可选择将数据驻留在欧盟或进行本地部署扫描；借助 BYOK，AI 在您自己的服务商账户上运行，并设有单次扫描支出上限。SSO/SAML、基于角色的访问控制和审计日志可作为附加功能提供，企业版已包含。

   仍由您负责的部分

   您的尽职调查、合同条款以及信息登记册。

本页概述了条例 (EU) 2022/2554 以及授权条例 (EU) 2024/1774 和 (EU) 2025/1190。微型企业和适用简化框架的实体承担的义务较轻。本页不构成法律意见。