CBB 网络安全规则：移动银行应用在每次发布和每年两次的测试中都要检查。

1. 01

   CBB Rulebook 第 1 卷，OM-5.5.25 和 OM-5.5.26

   评估应用、外部系统和第三方连接

   文本的内容

   定期开展技术评估，识别系统、应用和网络设备中潜在的安全漏洞。评估必须全面，覆盖内部技术、外部技术和与第三方的连接。内部技术的评估最好每月进行，面向公众的服务和系统的评估最好每周或更频繁地进行。外部技术指网站、应用和外部服务器等面向公众的技术；与第三方的连接包括与金融科技公司、技术提供商和外包服务商的任何 API 或其他连接。

   来源：CBB Rulebook 第 1 卷，OM-5.5.25 和 OM-5.5.26

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

   文本在外部技术的定义中点名了应用，因此移动应用及其调用的 API 属于评估范围，面向公众的系统适用最严格的频率。

   Ostorlab 如何提供帮助

   Mobile Agentic Deep Scan 在每次发布时测试商店版本及其背后的 API，AI 智能体的每个发现都附有可重放的有效漏洞利用。它通过测试应用和 SDK 调用的服务，追踪应用与第三方的连接。

   仍由您负责的部分

   评估计划、内部服务器和网络设备的扫描，以及剩余风险的处理计划。

2. 02

   CBB Rulebook 第 1 卷，OM-5.5.28 和 OM-5.5.61

   至少每年两次渗透测试

   文本的内容

   所有持牌机构必须至少每年两次对系统、应用和网络设备开展渗透测试，以验证现有安全控制的稳健性。测试必须模拟真实网络攻击，遵循 NIST 或 OWASP 等国际公认的基于风险的方法，同时覆盖灰盒和黑盒测试，由具备渗透测试服务认证资格和经验的安全专业人员执行，由至少每两年更换一次的内部和外部独立第三方实施，并在生产环境或其完全复制的环境中进行。测试报告和缓解措施必须保存五年，并在测试所在月份结束后的两个月内提交给 CBB。

   来源：CBB Rulebook 第 1 卷，OM-5.5.28 和 OM-5.5.61

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

   每年两次是下限，不是上限。移动版本发布远比这频繁，而应用及其调用的 API 都在范围内。

   Ostorlab 如何提供帮助

   Ostorlab 在两次半年测试之间的每次发布上，针对客户下载的版本开展工作，并使用您的测试账户开展登录后的灰盒测试。对于需要写入报告的每个发现，都能提供漏洞利用或请求与响应证据。

   仍由您负责的部分

   独立测试机构的选择与轮换、正式方法、报告以及向 CBB 提交。

3. 03

   CBB Rulebook 第 1 卷，OM-5.5.29 和 OM-5.5.30

   在 CBB 要求时开展红队演练

   文本的内容

   CBB 可根据需要要求开展额外的红队演练。红队是由不同背景的道德黑客组成的团队，用于检验组织蓝队的响应活动；它可能从网络、社会（针对人的行为）和物理（针对组织设施或第三方场所）三个层面发起攻击，目标是检验检测和响应能力，而不是发现尽可能多的漏洞。被要求开展红队演练的机构，必须在演练结束后一个月内向 CBB 提交结果，并附上处理所发现弱点的全面计划。

   来源：CBB Rulebook 第 1 卷，OM-5.5.29 和 OM-5.5.30

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

   红队演练是全机构范围的演练，不是应用测试。已知的应用和 API 问题越早关闭，演练效果越好。

   Ostorlab 如何提供帮助

   Ostorlab 不执行红队演练，也不取代红队演练。它帮助您在演练前关闭已知的应用和 API 问题，并在演练后复测整改计划中的应用和 API 项目。

   仍由您负责的部分

   演练范围的确定与实施、社会和物理层面，以及在一个月内向 CBB 提交报告。

4. 04

   CBB Rulebook 第 1 卷，OM-5.5.18(d)、(h) 和 (i)

   在开发阶段和部署后严格测试

   文本的内容

   预防措施必须包括在软件开发阶段以及部署后开展严格的安全测试，以限制漏洞数量，并建立获准在组织系统上存在或运行的应用程序和应用组件（如库和配置文件）白名单。移动设备管理（MDM）解决方案和 BYOD 安全政策必须通过加密、远程擦除和强制密码等措施，保护所有可访问银行系统、应用和网络的移动设备。

   来源：CBB Rulebook 第 1 卷，OM-5.5.18(d)、(h) 和 (i)

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

   应用的每次发布都是对银行外部技术的一次变更。文本要求在部署前后都进行测试，针对客户实际使用的版本。

   Ostorlab 如何提供帮助

   Ostorlab 从您的 CI/CD 流水线对每个构建运行自动扫描，并在无需手动触发的情况下监控商店版本。Mobile SAST 无需源代码即可处理 APK、AAB 或 IPA。SCA 清单就是获准组件清单，并附有证据。

   仍由您负责的部分

   安全开发政策、MDM 和 BYOD 控制，以及获准组件清单本身。

5. 05

   CBB Rulebook 第 1 卷，OM-5.5.15(d)、OM-5.5.27 和 OM-5.5.4(e)

   按期限管理漏洞和补丁

   文本的内容

   建立漏洞和补丁管理流程，包括整改流程，确保已识别的漏洞得到处理，并在与每个漏洞风险相称的时限内应用安全补丁。网络安全政策必须涵盖漏洞管理、安全应用开发和安全变更管理，董事会应在网络安全报告中收到渗透测试的结果。

   来源：CBB Rulebook 第 1 卷，OM-5.5.15(d)、OM-5.5.27 和 OM-5.5.4(e)

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

   应用中的库和 SDK 是您发布的软件。每一项都需要已知版本、出现漏洞时的严重级别，以及您能够证明的修复期限。

   Ostorlab 如何提供帮助

   SCA 通过指纹识别静态编译的库，并逐个版本将其与已知漏洞对照。发现被评为严重、高、中或低，在平台中或 Jira 和 ServiceNow 中作为工单跟踪，并在修复发布后复测。

   仍由您负责的部分

   服务器和基础设施的补丁、供应商维护合同，以及风险接受决策。

6. 06

   CBB Rulebook 第 1 卷，OM-3.2.1、OM-3.2.2、OM-3.2.4 和 OM-3.2.6

   为电子银行和 EFTS 采用客户强认证

   文本的内容

   持牌机构必须采取适当措施认证客户的身份和授权，并使用有助于不可否认性和明确交易责任的预定交易认证方法，制定识别电子资金转账发起人的详细程序，并在适当情况下进行回呼确认。客户强认证流程必须确保：无法从认证码的披露中推导出任何要素信息；无法根据已知的其他已生成代码生成新代码；代码无法被伪造。客户认证必须使用知识、持有和生物特征（固有）三个要素。

   来源：CBB Rulebook 第 1 卷，OM-3.2.1、OM-3.2.2、OM-3.2.4 和 OM-3.2.6

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

   应用负责采集认证要素，但强制执行必须在服务器端完成，即使应用或攻击者跳过了某个步骤。

   Ostorlab 如何提供帮助

   认证测试覆盖登录和注销、令牌刷新、超时、会话失效和客户强认证，包括增强验证流程以及攻击者试图操纵它们的方式，以及这些流程背后的 API 调用。

   仍由您负责的部分

   认证方法和阈值的选择，以及电子资金转账的回呼程序。

7. 07

   CBB Rulebook 第 1 卷，OM-3.1.2(b)、(e)、(f)；OM-3.3.1 至 OM-3.3.6

   测试 API 并控制对电子银行系统的访问

   文本的内容

   电子银行和电子资金转账的政策和程序必须涵盖应用程序接口（API）测试、用户认证、依据个人数据保护法保护客户数据机密性，以及通过价值、数量和速度限制等工具和措施对客户账户资金变动进行强化欺诈监控。持牌机构还必须确保电子银行和 EFTS 系统、数据库和应用的职责分离、适当的授权控制和访问权限、数据完整性、清晰的审计轨迹和日志留存。

   来源：CBB Rulebook 第 1 卷，OM-3.1.2(b)、(e)、(f)；OM-3.3.1 至 OM-3.3.6

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

   应用背后的 API 承载与应用相同的数据。文本要求测试它们并控制访问，欺诈限额在服务器端执行。

   Ostorlab 如何提供帮助

   Ostorlab 即使启用 TLS 证书固定也能拦截应用流量，并测试 API 的授权缺陷（BOLA、BFLA、IDOR）、令牌和会话滥用，以及枚举、重放和自动化等滥用行为，为每个发现提供请求与响应证据。

   仍由您负责的部分

   欺诈监控规则和限额、服务器补丁，以及审计轨迹和日志留存。

8. 08

   CBB Rulebook 第 1 卷，OM-4.2.1、OM-4.5.4、OM-4.9.2、OM-3.3.9 和 OM-3.3.10

   测试移动渠道的业务连续性

   文本的内容

   业务连续性计划必须涵盖数据备份与恢复、关键系统和活动的持续、替代通信安排，以及中断时客户能够及时取用资金。持牌机构必须为关键职能设定恢复时间目标（RTO）、恢复点目标（RPO）和最大可容忍中断时间，并经高级管理层批准，至少每年测试一次业务连续性计划，包括启用备用场地、供应商提供的恢复服务和重要记录的恢复。电子银行系统必须具备有效的容量、连续性和应急计划，以及覆盖内部和外部攻击的事件响应计划。

   来源：CBB Rulebook 第 1 卷，OM-4.2.1、OM-4.5.4、OM-4.9.2、OM-3.3.9 和 OM-3.3.10

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

   应用及其 API 是客户取用资金的关键服务的一部分。依赖故障时它们的行为是可以测试的。

   Ostorlab 如何提供帮助

   Ostorlab 在预发布或接近生产的环境中测试应用及其 API 中影响可用性和数据完整性的行为，包括错误处理、会话行为和业务逻辑限制，并提供可附入业务连续性计划评审的证据。

   仍由您负责的部分

   业务连续性计划本身、备用场地、备份、RTO 和 RPO 的批准，以及年度测试。

9. 09

   个人数据保护法（2018 年第 30 号法律）第 8、9、12 和 13 条

   依据 PDPL 保护个人数据

   文本的内容

   数据控制者必须实施适当的技术和组织措施，保护个人数据免遭意外或未经授权的破坏、意外丢失、篡改或披露，以及未经授权的访问或其他形式的未经授权处理，同时考虑最新技术安全措施、成本和所涉风险。这些措施必须记录在案，并可被相关方查阅。控制者必须选择能够提供充分保障的处理者，并通过书面合同使处理承担同等的安全和保密义务。个人数据不得未经同意披露，除非目的地提供充分保护、当局授权转移或适用法律规定的豁免，否则禁止向王国外转移个人数据。

   来源：个人数据保护法（2018 年第 30 号法律）第 8、9、12 和 13 条

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

   应用会存储和传输个人数据，其 SDK 常常将数据发送到第三方后端。这些数据流需要同样的技术和组织措施，以及同样的转移纪律。

   Ostorlab 如何提供帮助

   Ostorlab 在本地存储、缓存、日志和截图中查找会话令牌和个人数据，检查传输保护，并梳理应用及其 SDK 与哪些第三方后端交换数据。

   仍由您负责的部分

   数据保护计划、数据保护监护人、处理记录和转移授权。

10. 10

    CBB Rulebook 第 1 卷，OM-5.5.57 和 OM-5.5.58

    在一小时内向 CBB 报告重大网络安全事件

    文本的内容

    当发生或发现危及客户信息或中断影响运营的关键服务的网络安全事件时，无论内部还是外部，持牌机构必须立即在一小时内联系 CBB，并在两小时内提交网络安全事件报告 A 部分。B 部分在事件发生后 10 个日历日内提交，包含完整的根本原因分析、对业务运营和客户的影响、为阻止攻击和防止再次发生而采取的所有措施，并在事件完全解决前每周更新进展。

    来源：CBB Rulebook 第 1 卷，OM-5.5.57 和 OM-5.5.58

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

    从检测到通知只有一小时。准确了解攻击者能在您的应用和 API 中做什么，正是报告根本原因分析部分所需要的。

    Ostorlab 如何提供帮助

    Ostorlab 不向 CBB 报告事件，也不充当您的 SOC。它针对应用和 API 发现提供漏洞利用及请求与响应证据，为报告中的根本原因分析提供支撑。

    仍由您负责的部分

    事件响应流程、一小时内致电 CBB、报告各部分以及每周更新。

CBB 公开文本摘要，核对日期为 2026 年 9 月 27 日。操作风险管理模块最近一次更新为 2026 年 5 月。本页不构成法律意见。