FSCA 和 PA 联合标准:在每次发布前后评估您的移动银行应用。

Joint Standard 2 of 2024 要求金融机构定期开展漏洞评估和渗透测试,在开发期间测试 Web 应用和关键应用,并对通过互联网访问包含敏感信息应用的用户账户强制实施多因素认证。Joint Standard 1 of 2023 确立了 IT 治理与风险管理框架,POPIA 则增加了安全保护措施和不设风险门槛的违规通知义务。Ostorlab 在每次发布时测试您的应用及其背后的 API,覆盖登录后的流程。

  • 基于客户实际下载的版本,评估移动应用及其调用的 API
  • 使用您的测试账户测试登录、一次性验证码、增强验证和会话处理
  • 列出每个版本中的 SDK 和原生库,并将其与已知漏洞对应
  • 每项发现都以可重放的漏洞利用或请求和响应证据作为证明
扫描您自己的应用预约演示

从 App Store 或 Google Play 免费扫描您的应用,无需登录。

适用对象
联合标准中列明的银行、保险公司、市场基础设施、养老基金及其他金融机构
关键日期
Joint Standard 1 of 2023 自2024年11月15日起适用,Joint Standard 2 of 2024 自2025年6月1日起适用,事件通知模板自2026年9月1日起生效
重点
漏洞评估、渗透测试和应用安全测试、多因素认证与数据保护,以及 POPIA 的安全保护措施
主要参考
Joint Standard 2 of 2024 - Cybersecurity and Cyber Resilience Requirements
关键日期

移动渠道背后的文本

FSCA 和审慎监管局的两项联合标准、PA 的云计算通告以及 POPIA。以下日期对应本页引用的文本。

  1. 2013年11月26日

    POPIA 刊登于政府公报

    Protection of Personal Information Act 4 of 2013 在 Government Gazette 上发布。第九章限制个人信息的跨境转移。

  2. 2021年7月1日

    POPIA 全面生效

    POPIA 于2020年7月1日生效,一年宽限期于2021年6月30日结束。安全违规必须向 Information Regulator 报告。

  3. 2023年11月10日

    Joint Standard 1 of 2023

    FSCA 和审慎监管局发布《金融机构 IT 治理与风险管理要求》,这是该行业首个具有约束力的此类联合标准。

  4. 2024年5月17日

    Joint Standard 2 of 2024

    《网络安全与网络韧性要求》发布,涵盖基本要求、卫生实践、测试以及重大事件通知义务。

  5. 2024年11月15日

    Joint Standard 1 of 2023 生效

    IT 治理与风险管理要求对适用范围内的金融机构生效。

  6. 2025年6月1日

    Joint Standard 2 of 2024 生效

    与 Joint Communication 5 of 2024 一同发布的 Joint Notice 1 of 2024 确定网络安全要求的生效日期为2025年6月1日。

  7. 2025年7月25日

    云计算与数据离岸通告

    Joint Communication 2 of 2025 重申 PA 的 Directive 3 of 2018 和 Guidance Note 5 of 2018,并说明云计算和数据离岸的推荐实践,联合标准正在制定中。

  8. 2026年9月1日

    事件通知模板

    Joint Notice 2 of 2026 依据两项联合标准确定 Reporting of Material IT and Cyber Incident Template。银行通过 Umoja 门户提交,其他金融机构使用 FSCA 的 Joint Standards Submission Portal。

文本的要求

将联合标准和 POPIA 应用于您的移动应用

每条规则都说明:文本的内容、它对移动银行应用意味着什么、Ostorlab 如何提供帮助,以及哪些工作仍由您的团队负责。

  1. Joint Standard 1 of 2023,7.3(e) 和 9.3(a);Joint Standard 2 of 2024,7.1.1(d)、7.1.2 和 7.7.5(c)

    建立资产台账,包括第三方组件

    文本的内容

    Joint Standard 1 of 2023 要求 IT 风险管理框架识别并优先处理 IT 资产,保护其免遭未经授权的访问、滥用或欺诈性修改,并维护最新的 IT 资产台账。Joint Standard 2 of 2024 要求建立所有信息资产的台账,包括位置和所有者,定期审查且至少每两年一次;并要求制定第三方和开源软件代码的使用与更新政策,在集成前进行审查和测试。

    来源:Joint Standard 1 of 2023,7.3(e) 和 9.3(a);Joint Standard 2 of 2024,7.1.1(d)、7.1.2 和 7.7.5(c)

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

    移动银行应用是一种信息资产,捆绑了第三方 SDK 和原生库。每一个都应在台账中占有一席之地,注明版本和负责人。

    Ostorlab 如何提供帮助

    Ostorlab 列出每个版本中的 SDK 和原生库及其版本和在应用包中的位置,并显示应用及其 SDK 通过网络与哪些后端交换数据。

    仍由您负责的部分

    资产台账本身、第三方尽职调查和合同。

  2. Joint Standard 2 of 2024,7.7.2 和 7.7.3

    定期评估并渗透测试应用及其 API

    文本的内容

    金融机构必须定期对 IT 系统和信息资产开展漏洞评估,频率与其重要性及面临的安全风险相称。必须对关键 IT 系统和信息资产开展渗透测试,以深入评估其网络安全防御,测试方式可采用黑盒、灰盒或白盒,或按主管机关的要求组合使用。对于可从互联网直接访问的 IT 系统和信息资产,每次发生重大变更或更新时都必须开展渗透测试;没有重大变更的,至少每年一次。

    来源:Joint Standard 2 of 2024,7.7.2 和 7.7.3

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

    您的移动银行应用及其调用的 API 可直接从互联网访问。请为每次重大发布和至少每年一次的测试做好规划,并覆盖登录后的测试。

    Ostorlab 如何提供帮助

    AI 智能体渗透测试在登录后,针对您发布的版本测试应用及其 API,AI 智能体的每个发现都附有可重放的有效漏洞利用。发现会被评级、以工单形式跟踪,并在修复后复测。

    仍由您负责的部分

    选择年度渗透测试的实施方、黑盒或灰盒决策、生产环境测试,以及向治理机构报告。

  3. Joint Standard 2 of 2024,7.2.4 和 7.7.5

    内建安全,并在开发期间测试应用

    文本的内容

    该标准要求采用安全设计方法,将安全性融入软件开发的每个阶段,以尽量减少系统漏洞并缩小攻击面。与访问控制、认证、交易授权、数据完整性、日志、审计跟踪、安全事件跟踪和异常处理相关的安全要求,必须在开发或采购的初始阶段明确规定;对业务关键应用的变更必须经过审查和测试。必须采用安全编码、源代码审查和应用安全测试标准,并在开发和实施期间测试 Web 应用和关键应用的安全功能。

    来源:Joint Standard 2 of 2024,7.2.4 和 7.7.5

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

    应用的每次发布都是对面向互联网渠道的一次变更,应在进入商店之前通过自动化安全测试,包括其捆绑的 SDK 和库。

    Ostorlab 如何提供帮助

    Mobile SAST 无需源代码即可直接分析 APK、AAB 或 IPA,并对嵌入的 SDK 进行污点分析。Mobile DAST 运行应用进行测试,两者都在每次构建时从 CI/CD 流水线运行。

    仍由您负责的部分

    安全编码标准、开发人员培训、人工代码审查和发布审批。

  4. Joint Standard 2 of 2024,7.7.6 和 8.5

    按严重性、优先级和补丁期限进行修复

    文本的内容

    修复流程必须包括问题的严重性评估和分类、根据所构成风险的优先级排序、不同严重性问题的修复时限,以及在适当情况下的风险评估和缓解策略。网络安全测试中发现的所有问题,以及源代码审查和应用安全测试中发现的软件缺陷,都必须跟踪;已知的重大问题和安全缺陷必须在生产部署前修复。安全补丁必须在与风险相称的时限内应用,无补丁时采取补偿性控制,生产应用前先行测试,无法应用补丁时制定带时间表的修复计划。

    来源:Joint Standard 2 of 2024,7.7.6 和 8.5

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

    应用或 API 中的每项发现都需要严重性评级、修复期限和记录。第三方库是最容易被遗忘的部分。

    Ostorlab 如何提供帮助

    Ostorlab 将每项发现评为严重、高、中或低,在平台中或 Jira 和 ServiceNow 中以工单形式跟踪,并在修复后复测。组件发现会附上升级或替换建议。

    仍由您负责的部分

    补丁窗口、服务器和基础设施的补丁修复、风险接受和生产部署决策。

  5. Joint Standard 2 of 2024,7.2.2、8.2 和 8.3

    面向互联网账户的身份、访问与多因素认证

    文本的内容

    对信息资产的访问必须限于经授权的用户、进程和设备,并根据评估的未授权访问风险进行管理,具备身份管理和访问控制机制、安全和访问控制政策、仅允许从安全设备和连接进行远程访问,以及对远程访问实施强认证。每个管理账户都必须受到保护,防止未经授权的访问和使用;特权访问应按需授予并记录活动。对可访问关键系统功能的用户、所有管理和特权账户,以及所有通过互联网访问包含敏感信息应用的用户账户,都必须实施多因素认证。

    来源:Joint Standard 2 of 2024,7.2.2、8.2 和 8.3

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

    移动应用正是多因素认证规则所指的那类应用。无论应用发送什么,第二因素都必须由服务器强制执行。

    Ostorlab 如何提供帮助

    认证测试覆盖登录和注销、令牌刷新、超时、会话失效和多因素认证的强制执行(包括增强验证流程),以及其背后的 API 调用。

    仍由您负责的部分

    认证方式的选择、特权访问管理、访问审查和设备策略。

  6. Joint Standard 2 of 2024,7.2.3;Joint Standard 1 of 2023,10

    保护设备上和传输中的数据

    文本的内容

    Joint Standard 2 of 2024 要求对处于传输、存储和使用中的敏感信息制定数据防泄漏政策;采取措施防止和检测系统和终端设备中数据的未授权访问、修改、复制、传输和窃取;对存储在系统和终端设备中的敏感信息,按风险程度进行加密或访问控制;并且只使用经授权的系统和设备处理敏感信息。Joint Standard 1 of 2023 要求采取措施保护客户的个人账户和交易数据,实施带异常监控的逻辑访问控制,并防范终端设备的数据窃取、丢失和泄漏。

    来源:Joint Standard 2 of 2024,7.2.3;Joint Standard 1 of 2023,10

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

    密码、令牌和客户数据不应以明文形式留在手机上,也不应在无保护的情况下传输到后端。已 Root 或越狱的设备会削弱上述每一项控制。

    Ostorlab 如何提供帮助

    Ostorlab 在本地存储、缓存、日志和截图中查找会话令牌和个人数据,检查传输保护,并测试应用在 Root 和越狱环境中的行为。

    仍由您负责的部分

    数据分类、DLP 工具、移动设备管理和密钥管理。

  7. Joint Standard 2 of 2024,7.2.6

    管理密码学并保护密钥

    文本的内容

    使用密码学时,政策、标准和程序必须涵盖密钥的生成、分发、安装、更新、吊销、恢复和到期。密码算法必须来自成熟的国际标准;密钥必须安全生成,并在强化且防篡改的系统中防止未经授权的泄露;过期或已吊销的密钥必须以不可恢复的方式销毁;所有算法都必须针对既定的安全目标经过严格测试或审核。

    来源:Joint Standard 2 of 2024,7.2.6

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

    证书固定、代码签名和密钥库的使用都是应用中的密码学。应用包或密钥库中的内容可能在已修改的设备上被攻击。

    Ostorlab 如何提供帮助

    Mobile Shielding Scan 在运行时尝试绕过 Root 和越狱检测、防篡改以及 TLS 证书固定,并显示哪些防护有效、哪些被绕过。Ostorlab 还会在应用包中发现密钥和机密信息。

    仍由您负责的部分

    密钥管理系统、HSM、证书生命周期和算法选择。

  8. Protection of Personal Information Act 4 of 2013,第19、21、22 和 72 条

    满足 POPIA 的保护措施和违规通知义务

    文本的内容

    POPIA 要求责任方采取适当、合理的技术和组织措施,保障个人信息的完整性和机密性。责任方必须识别可合理预见的内部和外部风险,建立并维护针对这些风险的防护措施,定期核实防护措施得到有效实施,并针对新风险或缺陷进行更新。必须以书面合同要求运营方维持相同的安全措施;当有合理理由相信未经授权的人员访问了个人信息时,运营方必须立即通知责任方。当有合理理由相信个人信息已被未经授权的人员访问或获取时,责任方必须尽快通知 Information Regulator,并在适用例外之外通知数据主体。个人信息向境外转移需要具备充分的保护水平或第72条规定的其他依据。

    来源:Protection of Personal Information Act 4 of 2013,第19、21、22 和 72 条

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

    应用测试是验证设备和 API 中第19条防护措施的方式之一。Information Regulator 指出,报告没有风险门槛:每一起安全违规都必须报告,而且不必等到确认之后。

    Ostorlab 如何提供帮助

    Ostorlab 测试应用及其 API 中的技术控制措施,并为每项结果提供证据。安全违规的认定和通知仍由您的信息官负责。

    仍由您负责的部分

    信息官职责、违规评估、向 Regulator 和数据主体通知,以及跨境转移决策。

  9. Joint Standard 1 of 2023,15.1;Joint Standard 2 of 2024,9.1;Joint Notice 2 of 2026

    按规定形式通知重大事件

    文本的内容

    两项联合标准都要求金融机构在将系统故障、网络事件或信息安全违规归类为重大事件后,以当局确定的形式和方式通知主管机关。与 Joint Communication 5 of 2026 一同发布的 Joint Notice 2 of 2026 确定了 Reporting of Material IT and Cyber Incident Template,自2026年9月1日起生效。银行、互助银行、保险公司及其控股公司通过 Umoja 门户提交;其他适用金融机构使用 FSCA 的 Joint Standards Submission Portal。

    来源:Joint Standard 1 of 2023,15.1;Joint Standard 2 of 2024,9.1;Joint Notice 2 of 2026

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

    您的事件分类和通知流程需要该模板、门户,以及模板封面页规定的时限。扫描证据有助于确定影响范围。

    Ostorlab 如何提供帮助

    Ostorlab 不负责事件的分类或通知。它为您提供事件背后漏洞或控制失效的证据,并在之后复测修复结果。

    仍由您负责的部分

    分类、通知、与监管机构和客户的沟通,以及取证。

  10. Joint Communication 2 of 2025,第4节;PA Directive 3 of 2018;Joint Standard 1 of 2023,7.3(i)

    治理云计算使用和数据离岸

    文本的内容

    2025年7月25日发布的 Joint Communication 2 of 2025 重申了面向银行的 PA Directive 3 of 2018 和 Guidance Note 5 of 2018,并说明了云计算和数据离岸的推荐实践:与风险偏好一致的风险导向方法;涵盖明确政策、董事会批准的数据战略和数据治理框架的治理;关注合同和法律要求;以及在战略投资前开展尽职调查。离岸是指在南非边境之外存储或处理数据。当局表示正在制定云计算和数据离岸联合标准。Joint Standard 1 of 2023 还要求审慎筛选服务提供商和承包商,并通过合同保护敏感或机密信息。

    来源:Joint Communication 2 of 2025,第4节;PA Directive 3 of 2018;Joint Standard 1 of 2023,7.3(i)

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

    如果应用的后端或其 SDK 将个人信息发送到南非境外的服务,POPIA 第72条和云计算方面的期望都会适用。应用仍可在数据所在的位置进行扫描。

    Ostorlab 如何提供帮助

    本地部署扫描在您控制的基础设施上、在您的网络内运行,可扫描防火墙或 VPN 后的预发布应用、API 和代码仓库。

    仍由您负责的部分

    云战略、尽职调查、合同、数据本地化决策,以及即将出台的联合标准。

本页概述了公开的联合标准、审慎监管局通告以及 POPIA 文本,核对日期为2026年9月27日。联合标准并未点名移动应用:它们适用于一般 IT 系统、信息资产和应用,本页将其应用于移动渠道。本页不构成法律意见。

对应关系

逐项梳理联合标准的控制措施

联合标准和 POPIA 所指向的控制措施、Ostorlab 如何在您的应用及其 API 中测试这些控制,以及您可以留存的证据。

逐项梳理联合标准的控制措施
控制措施Ostorlab 如何提供帮助您留存的证据
应用及其 API 的漏洞评估JS2 7.7.2、7.7.3在登录后,针对您发布的版本,由 AI 智能体对应用及其 API 进行渗透测试。 详情 AI 智能体的每个发现都附有可重放的有效漏洞利用,另有覆盖率热力图
重大变更时及至少每年一次的渗透测试JS2 7.7.3(a)(iii)在每次发布时测试面向互联网的应用和 API,使年度测试不会从过时的基线开始。 详情 每个版本的扫描结果,以及每项发现的可重放漏洞利用
开发期间的应用安全测试JS2 7.7.5对二进制文件运行 Mobile SAST,对运行中的应用运行 Mobile DAST,每次构建时从 CI/CD 执行。 详情 包含反编译代码上下文、流量、堆栈跟踪和截图的发现
第三方和开源组件JS2 7.7.5(c)、7.7.6(b)(iii)通过指纹识别静态编译库,并逐个版本将其与已知漏洞对应。 详情 已对应的漏洞及升级或替换建议,并跨版本跟踪关闭情况
软件台账和版本JS1 9.3(a);JS2 7.1.1(d)列出每个版本中的 SDK 和原生库及其版本,并显示应用及其 SDK 与哪些后端通信。 详情 每个版本的组件标识、版本和在应用包中的位置
凭据和特权访问JS2 7.2.2、8.2在应用包中查找 API 密钥、令牌和凭据,并验证它们是否可用。 详情 经过验证的密钥,以及它们暴露的权限和服务
面向互联网账户的多因素认证和会话JS2 8.3、7.2.2(a)使用一次性验证码登录,测试多因素认证的强制执行和增强验证流程,然后测试注销、令牌刷新、超时和会话失效。 详情 有关登录、增强验证和会话流程的发现,附复现步骤和请求日志
设备和传输中的数据保护JS2 7.2.3;POPIA 第19条在存储、缓存、日志和截图中查找令牌和个人数据,并检查传输保护。 详情 文件系统证据,显示写入了什么、写入位置和时间
密码学与防篡改JS2 7.2.6在运行时尝试绕过 Root 和越狱检测、防篡改以及 TLS 证书固定。 详情 加固评分,以及每项失效防护的绕过证据
修复期限与复测JS2 7.7.6、8.5将发现归入工单,修复后复测,并跨版本跟踪组件关闭情况。 每项发现的工单历史和复测结果

Ostorlab 测试应用及其 API 中的控制措施。治理、SOC 监控、事件响应和报告、模拟演练、备份和恢复、云合同以及物理安全仍由您的团队负责。

行动计划

需要在移动应用中测试的联合标准控制措施

面向安全和 IT 风险团队的实用清单,依据 Joint Standard 2 of 2024、Joint Standard 1 of 2023 和 POPIA 编制。

  1. 将移动应用纳入范围

    将移动应用纳入漏洞评估和渗透测试计划的范围,设定频率并加入发布前环节。

  2. 面向互联网的 API

    将应用调用的 API 作为面向互联网的系统进行评估:授权、令牌、会话处理,以及请求其他客户数据的情况。

  3. 每次发布

    对每个构建运行自动化应用安全测试,并扫描每个商店版本,而不仅仅是上个季度测试过的版本。

  4. 组件与期限

    为每个版本中的 SDK 和库保留带版本信息的清单,并按严重性设定修复期限。

  5. 密钥与凭据

    检查应用包中的 API 密钥、令牌和凭据,轮换所有仍然可用的凭据,并测试特权访问路径。

  6. 多因素认证与会话

    验证面向互联网的登录是否需要在服务器端校验第二因素,并测试令牌刷新、超时和会话失效。

  7. 数据与防篡改

    在存储、缓存、日志和截图中查找令牌和个人数据,并在已修改的版本上测试 Root、越狱、防篡改和证书固定。

  8. 报告、复测与通知

    通过复测跟踪发现直至关闭,按确定的模板和门户演练重大事件通知,并准备好向 Information Regulator 报告 POPIA 违规的路径。

此清单仅为建议,并非联合标准模板。POPIA 的通知义务由您的信息官承担,也不构成法律意见。

来源

本页所依据的官方文本,核对日期为2026年9月27日。

FAQ

常见问题

关于覆盖范围、部署配置以及结果如何送达您团队的直接解答。

没有找到答案?预约演示或联系我们。

按照联合标准所描述的方式评估您的移动银行应用

先从应用商店免费扫描您的应用,或预约演示,与我们的团队一起对您的应用和 API 运行登录后测试。