巴基斯坦国家银行：在每次上线前测试您的移动银行应用。

1. 01

   BPRD 2023 年第 04 号通函，附件 A，2(vii) 和 2(viii)

   在上线前审查每个新的或变更的数字产品

   文本的内容

   对新的数字产品和服务以及对现有产品和服务的任何修改开展全面的信息安全审查，涵盖人员、流程和技术。在部署到生产环境和上线之前，必须修复这些审查中发现的薄弱环节以及所有严重、高和中风险漏洞，并通过验证加以控制。

   来源：BPRD 2023 年第 04 号通函，附件 A，2(vii) 和 2(viii)

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

   移动应用的每个版本都会改变一个数字产品。它需要接受安全审查，并且在商店更新上线之前，每项中、高或严重风险的发现都必须修复并复测。

   Ostorlab 如何提供帮助

   从您的 CI/CD 流水线对每个构建运行自动扫描。Mobile SAST 直接分析 APK、AAB 或 IPA，无需源代码，Mobile DAST 则运行应用。发现会被评为严重、高、中或低风险，以工单形式在平台中或 Jira 和 ServiceNow 中跟踪，并在修复发布后进行复测。

   仍由您负责的部分

   审查基线、审查中涉及人员和流程的部分，以及上线决策。

2. 02

   BPRD 2023 年第 04 号通函，附件 B（常见问题解答），管理控制 2(vii)

   定期开展应用安全审查

   文本的内容

   SBP 关于 2023 年措施的常见问题解答指出，受监管实体必须定期开展应用安全审查，包括漏洞评估、渗透测试和源代码审查，并及时处理和修复所有已识别的漏洞。每个实体根据最佳实践和自身的风险评估制定各自的审查基线。

   来源：BPRD 2023 年第 04 号通函，附件 B（常见问题解答），管理控制 2(vii)

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

   仅靠发布前检查还不够。应用及其 API 还需要定期循环开展漏洞评估、渗透测试和代码审查，并留存发现已修复的记录。

   Ostorlab 如何提供帮助

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

   仍由您负责的部分

   后端的源代码审查、审查计划以及基线本身。

3. 03

   《企业技术治理与风险管理框架》，2.7

   建立包含漏洞评估和渗透测试的测试计划

   文本的内容

   建立全面的测试计划，定期验证信息安全环境的有效性。根据业务的复杂程度，采用漏洞评估并随后开展验证测试以确认差距已弥补、基于场景的测试、定期渗透测试（在重大更新和部署时对内部系统进行测试），并设立独立的质量保证职能，测试内部开发成果中的漏洞。各项测试的频率由政策规定。

   来源：《企业技术治理与风险管理框架》，2.7

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

   您的政策决定应用的测试频率。应用或其后端的重大版本发布，自然是开展渗透测试的触发点，而每次评估都需要一次后续测试，证明差距已经弥补。

   Ostorlab 如何提供帮助

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

   仍由您负责的部分

   基于场景的测试和恢复测试、测试政策及其频率。

4. 04

   BPRD 2016 年第 07 号通函；PSD 2018 年第 09 号通函

   对网络安全控制开展独立评估

   文本的内容

   银行、DFI 和小额信贷银行必须确保定期对其网络安全控制的充分性和有效性开展独立评估。评估可以包括由独立于受审查领域的人员，或在内部团队缺乏专业能力时由具备足够 IT 安全经验的外部方开展的漏洞评估和渗透测试。2018 年，SBP 还要求对包括网上银行和移动银行在内的替代交付渠道开展内部漏洞评估和渗透测试，并进行独立第三方审查。

   来源：BPRD 2016 年第 07 号通函；PSD 2018 年第 09 号通函

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

   测试应用的人员应独立于开发应用的团队。对于移动银行，SBP 已经同时要求开展内部测试和第三方审查。

   Ostorlab 如何提供帮助

   Ostorlab 测试客户下载的版本及其调用的 API。由您的安全团队或第二道防线团队执行测试并掌握结果，与开发人员相互独立。

   仍由您负责的部分

   判断某项测试是否满足独立性要求，以及聘请外部评估方。

5. 05

   《网上银行安全条例》，1 和 2.2.1；BPRD 2023 年第 04 号通函，附件 A，3-I(iv)

   至少采用双因素认证，并控制会话

   文本的内容

   银行必须至少采用双因素认证对网上银行客户进行认证（例如密码加一次性令牌），并为高额交易增加分层安全措施。认证控制须考虑登录失败次数、密码更改频率、会话超时以及基于预设条件的重新认证。无论客户使用何种访问设备，这些条例均适用；SBP 的 2023 年措施还规定，一次性密码必须具有合理的长度和适当的有效期。

   来源：《网上银行安全条例》，1 和 2.2.1；BPRD 2023 年第 04 号通函，附件 A，3-I(iv)

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

   失败尝试后的锁定、会话过期、高额转账的重新认证以及一次性密码有效期，都是应用及其后端中可测试的设置。

   Ostorlab 如何提供帮助

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

   仍由您负责的部分

   选择认证因素和策略参数，例如锁定阈值和一次性密码有效期。

6. 06

   BPRD 2023 年第 04 号通函，附件 A，3-A(iii)、(v)、(vi)、(viii) 和 (ix)

   绑定设备并保护凭据重置

   文本的内容

   通过设备指纹或设备绑定注册客户设备，并在出现任何新设备时立即通知客户。凭据重置只能在已注册的设备上进行，并采用一次性密码自动获取或自动填充以及限制手动输入的发送方绑定。对于新注册的客户，在激活移动应用之前，以及在设备、手机号码、电子邮件、交易限额和密码重置等关键账户变更之前，适用 2 小时的冷静期。在注册流程完成之前，不得确认账户是否存在。

   来源：BPRD 2023 年第 04 号通函，附件 A，3-A(iii)、(v)、(vi)、(viii) 和 (ix)

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

   这些控制必须在后端有效，而不仅仅体现在应用界面上。直接发送到 API 的请求也应受到同样的设备检查、同样的冷静期和同样的静默注册约束。

   Ostorlab 如何提供帮助

   Ostorlab 使用您的测试账户完成短信、电子邮件或 TOTP 一次性验证码，测试 MFA 强制执行和增强验证流程（包括攻击者试图操纵它们的方式），以及账户变更背后的 API 调用。API 测试覆盖枚举、重放和自动化等滥用行为。

   仍由您负责的部分

   设备绑定设计、NADRA 生物特征验证、回拨确认以及客户通知。

7. 07

   BPRD 2023 年第 04 号通函，附件 A，3-B(v) 和 3-E

   加密和掩码处理客户数据

   文本的内容

   根据数据的分类和敏感程度，在交易的所有阶段对传输中和静态数据进行加密，包括个人身份信息和支付卡数据。客户信息以哈希或加密形式存储或传输，采用 AES 256 和 SHA256 等未过时的算法；生物特征信息绝不以未加密形式存储或传输；卡号等关键信息须进行掩码处理。

   来源：BPRD 2023 年第 04 号通函，附件 A，3-B(v) 和 3-E

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

   应用是交易的一个阶段。它写入设备、记录到日志或通过网络发送的内容都在范围之内。

   Ostorlab 如何提供帮助

   Ostorlab 在本地存储、缓存、日志和截图中查找会话令牌和个人数据，检查会削弱传输和会话保护的错误配置，并测试交易背后的 API。

   仍由您负责的部分

   密钥管理、数据分类以及服务器上的加密。

8. 08

   BPRD 2023 年第 04 号通函，附函及附件 A，4(iii)(f) 和 4(v)

   能够证明您的控制措施已经落实

   文本的内容

   未能在规定时限内落实控制措施的银行和小额信贷银行，除受到执法行动外，还须在欺诈报告后三个工作日内向受害客户作出赔偿。根据责任框架，如果金融机构无法证明交易是通过客户已注册的设备执行的，须向客户作出赔偿；如果任何规定的控制措施未落实或已失效，发起方金融机构须向客户作出赔偿。

   来源：BPRD 2023 年第 04 号通函，附函及附件 A，4(iii)(f) 和 4(v)

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

   当出现欺诈索赔时，问题在于您的控制措施是否存在并且有效。每个版本的测试结果可以帮助您回答这个问题。

   Ostorlab 如何提供帮助

   扫描结果、附有复现步骤的发现以及复测结果，为您逐个版本留下注明日期的记录，说明应用的控制措施如何接受测试和修复。

   仍由您负责的部分

   欺诈监控、在 FTDH 中的争议处理以及赔偿决定。

9. 09

   《云服务提供商外包框架》，T 节

   至少每年测试一次云托管系统

   文本的内容

   至少每年一次，对托管在云服务提供商处的系统开展漏洞评估、渗透测试和基于场景的安全测试，并考虑云服务特有的威胁，例如薄弱的应用程序编程接口。云工作负载中的漏洞按风险分类、跟踪和修复，包括修复后的验证。

   来源：《云服务提供商外包框架》，T 节

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

   如果您应用背后的后端或 API 运行在云端，它们至少每年需要接受一次评估和渗透测试，而 API 薄弱环节被明确列为需要覆盖的场景。

   Ostorlab 如何提供帮助

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

   仍由您负责的部分

   云基础设施的测试、云服务提供商自身的评估以及数据中心审查。

本页概述了 SBP 的公开文本，核对日期为2026年9月27日。部分文本仅适用于银行和小额信贷银行，已在文中注明。本页不构成法律意见。