RMiT 源代码审查：BNM 的要求，以及如何证明

假设吉隆坡一家银行支付团队的开发人员，在某个星期四把一项改动合并进 DuitNow 转账服务。六个月后，技术审计师从发布记录中挑出这项变更，只问一个问题：它的源代码审查记录在哪里？

如果老实的回答是"有人看过，但没人留下记录"，那么在审计看来，这次审查就等于没有发生。

RMiT（Risk Management in Technology，技术风险管理）是马来西亚国家银行（BNM）针对金融机构的技术风险政策。下文把 RMiT 中每一条涉及代码的规定，转换成审计师会要求查看的证据。这就是 RMiT 源代码审查在实践中的含义。

本文写给银行、保险公司或金融科技公司里负责应对审计的人，也写给为它们开发系统的供应商。

文中的段落编号来自 BNM 的 2026年9月25日发布的 RMiT 政策文件（BNM/RH/PD 028-98）。该文件注明的生效日期为 2025年11月28日，个别段落另有规定的除外。请到 bnm.gov.my 查看是否有更新版本。

本文是对公开监管文本的浅白解读，不构成法律意见。请与您的合规团队确认具体义务。

RMiT 源代码审查要点速览

以下用浅白的话总结 RMiT 对代码的要求。文章其余部分会逐条解释，并说明背后需要的证据。

如何阅读 RMiT 的条文编号

RMiT 按段落为规则编号，并把每段标为 "S" 或 "G"。S 段是强制性标准；G 段是指引。附录则包含详细清单。例如，附录 5 列出网络韧性控制措施，其中 E 部分涉及 API 安全，而第 11.5 段把附录 5 定为强制。

本文中的"第 10.10 段"即 RMiT 第 10.10 段。若某段只是指引，我们会特别说明。

RMiT 对源代码的规定

RMiT 原文对两者的区分很明确。S 段 "must be complied with"（必须遵守），不遵守 "may result in enforcement action"（可能招致执法行动）。G 段则是 "encouraged to be adopted"（鼓励采纳）的建议。

请记住这个区分。大家常引用的几条代码扫描条文，其实是指引，不是标准。

对自有代码的强制要求

每项变更上线前都要审查。 关键系统源代码的变更必须 "subject to adequate source code reviews"（接受充分的源代码审查，第 10.10 段）。审查要确认代码安全，并且 "developed in line with recognised coding practices"（按公认的编码规范开发）。审查必须在 "prior to introducing any system changes"（引入任何系统变更之前）完成。

关键系统，是指支持关键银行、保险、伊斯兰保险（takaful）、支付、投资或交易服务的任何应用系统。

每项变更都要独立批准。 您可能见过有人把第 10.10 段概括为要求"独立"代码审查。现行文本写的是 "adequate"（充分），而不是 "independent"（独立）。独立性出现在下一段：机构须制定程序 "independently review and approve system changes"（独立审查并批准系统变更，第 10.11 段）。

实践中两者都需要：一次代码审查，加上一次对变更的独立批准。当编码智能体编写变更时，同一条规则也决定了 谁来审查 AI 生成的代码、谁有权批准。

定期测试 API。 机构必须 "conduct periodic security assessments on APIs, including penetration testing and static / dynamic security testing"（定期对 API 进行安全评估，包括渗透测试和静态/动态安全测试，附录 5，E 部分 1(h)）。这是强制要求，因为第 11.5 段规定附录 5 为强制。

检查 API 中的第三方代码。 API 开发还必须遵循安全编码，包括 "validating security of third party code and libraries"（验证第三方代码和库的安全性，附录 5，E 部分 1(c)）。

如果您为银行或保险公司开发软件

供应商的角色就在这里。RMiT 不直接约束您；它约束机构，再由机构通过合同约束您。

当第三方开发或维护关键系统时，机构必须要求该供应商 "demonstrate that it adopts secure by design principles in IT system development methodology"（证明其在 IT 系统开发方法中采用安全设计原则，第 10.12(b) 段）。供应商还必须确保 "the source code continues to be readily accessible"（源代码持续可随时获取，第 10.12(c) 段）。

另外，机构的供应商尽职调查必须考虑一系列列明的风险（第 10.47 段）。清单中包括 "secure system development lifecycle"（安全的系统开发生命周期）和 "vetting of third party or open source software"（审核第三方或开源软件，附录 8）。

自动化是强制的；工具和 SBOM 是指引

快速迭代的团队必须自动化安全检查。 若机构采用 DevOps 等快速开发方法，它 "shall automate the IT security compliance review"（须将 IT 安全合规审查自动化，第 10.6 段），其中包括发现和测试安全漏洞。

代码扫描工具是建议，不是要求。 机构 "may deploy automated tools"（可部署自动化工具），用于开发、测试、变更管理、"code scanning and software version control"（代码扫描和软件版本控制，第 10.14 段，指引）。

SBOM 是建议，不是要求。 机构可考虑 "adopting Software-Bill-of-Materials (SBOM)"（采用软件物料清单，第 10.15 段，指引）。SBOM 是软件中所有第三方组件的清单。同一段还建议制定开源软件安全政策。

这两段指引反映了 BNM 眼中的良好做法，但并不构成必须购买扫描器的独立义务。

如果您属于国家关键信息基础设施

部分机构被指定为 NCII（国家关键信息基础设施）实体。对它们而言，RMiT 纳入了《2024年网络安全法》（Cyber Security Act 2024）下的银行业实务守则（附录 12）。

守则要求制定与 OWASP Top 10 对齐的安全编码指南。OWASP Top 10 是最常见 Web 应用弱点的标准清单。守则也要求部署前测试，包括 "Validation of compliance with secure coding guidelines."（验证是否符合安全编码指南）。守则须经马来西亚国家网络安全局 NACSA 的总执行长（Chief Executive）认可后才生效。

RMiT 审计证据：审计师和 BNM 要看什么

把强制段落当作证据请求来读，就能整理出一份工作清单。这是我们在内部技术审计或供应商尽职调查之前会准备的清单。

• 关键系统每次变更的审查记录。 写明谁审查、依据哪些编码规则、结果如何，日期须早于发布（第 10.10 段）。
• 每项变更的独立批准（第 10.11 段）。RMiT 还要求 "appropriate segregation of duties throughout the SDLC"（在整个 SDLC 中适当分离职责），所以实践中批准人不能是作者本人。
• API 测试结果。 保留定期的静态和动态安全测试结果，以及渗透测试报告（附录 5，E 部分）。
• 书面编码标准。 它让"公认的编码规范"有具体依据（第 10.10 段）。NCII 实体还需要一份与 OWASP Top 10 对齐的标准（附录 12）。
• 供应商证据。 收集供应商的安全 SDLC 说明及其执行证明（第 10.12 段）。确认源代码保持可获取，并保存尽职调查的答复（附录 8）。
• 开源和第三方组件清单，最好是 SBOM，并附审核结果（附录 8）。SBOM 本身属于指引（第 10.15 段）。
• 已知漏洞状态。 系统必须 "not running with known security vulnerabilities"（不带已知安全漏洞运行，第 10.17 段）。
• 差距分析。 机构必须在 "no later than 90 days after the issuance date of this policy document"（不迟于本政策文件发布后 90 天）向 BNM 提交差距分析和行动计划（第 18.1 段）。已按旧版本提交的机构，须继续找出 "any new gaps against the enhanced or revised requirements"（针对强化或修订要求的任何新差距），并在 BNM 要求时提供年度评估。

其中最难事后补齐的有两项：每次变更的审查记录，以及组件清单。如果工具在每个拉取请求（PR）上自动写下这两项，保存成本很低；六个月后再回头重建，就非常痛苦。

SonarQube 如何按版本支持 RMiT 证据

SonarQube 不会让您自动符合 RMiT。它擅长的是在每次变更时，自动写下大部分 RMiT 源代码审查证据。能提供哪些证据，取决于版本。

各版本能提供什么

每次变更的审查记录：Developer edition 及以上。 每个 PR 在合并前都会被分析。如果新代码违反您的规则，质量门（quality gate）可以阻止合并。分析历史为每次变更的审查提供证据支持（第 10.10 段）。质量配置（quality profile）就是写成文字的编码标准。

免费的 Community Build 只分析主分支，因此无法提供每次变更的记录。我们对 SonarQube Community、Developer 与 Enterprise 的比较说明了每个版本增加了什么。

审计师可以归档的文件：Enterprise edition。 SonarQube Server Enterprise 增加了尽职调查团队或审计师可以归档的材料：

• 合规报告，对照 OWASP Top 10、CWE Top 25（MITRE 列出的最危险软件弱点）和 PCI DSS（支付卡行业安全标准）；
• PDF 报告；
• 监管报告，一个包含质量门状态、评级和质量配置的 ZIP 文件；
• 审计日志。

有一点要注意：审计日志的清理任务默认每月删除记录，所以请在审计期开始前调高保留期限。

组件清单和 SBOM：Advanced Security 附加组件。 它支持供应商尽职调查中的开源审核（附录 8）。SonarQube Advanced Security 是 Server Enterprise 起提供的付费附加组件，增加软件成分分析（扫描您的第三方依赖项）。它还能以 CycloneDX 或 SPDX 这两种标准 SBOM 格式导出 SBOM。SBOM 不会被保存，所以每次发布都要导出一份。

修复问题：Remediation Agent。 SonarQube Remediation Agent 会提出修复方案，并以 PR 的形式提交给您审查，每个修复都会重新经过 Sonar 的分析。

逻辑和访问控制缺陷：Hunter Agent。 SonarQube Hunter Agent 寻找失效的访问控制和业务逻辑缺陷，也就是 PCI DSS 6.2.4 点名的攻击类别（见下文），以及身份验证缺陷。

两个智能体都是独立订阅。在 SonarQube Server 上，它们需要 Enterprise edition 2026.5 或更高版本。SonarQube Cloud 上的 Hunter Agent 需要 Enterprise 计划。两者都不能取代您的审查人员，也不能取代独立批准（第 10.11 段）。

代码在哪里运行。 对受监管机构来说，这一点可能决定版本选择。SonarQube Cloud 只把数据存储在欧盟或美国（截至 2026年10月），注册后无法更改区域，也没有亚太区域。

SonarQube Server 是自行管理的，由您决定在哪里运行，包括您自己的基础设施。许可证按代码行数计价；请参阅 SonarQube 的定价方式。

它不涵盖什么。 SonarQube 的核心是静态分析。它不能取代 RMiT 同样要求的 API 动态测试和渗透测试（附录 5，E 部分），也不能取代每项变更的独立批准。请把它当作证据中的一项控制措施，而不是全部。

处理银行卡数据？也适用 PCI DSS

PCI DSS v4.0.1 从另一个角度要求大致相同的证据：

• 发布前审查自定义代码。 定制和自定义软件必须 "reviewed prior to being released into production or to customers"（在发布到生产环境或交付客户之前经过审查，要求 6.2.3）。其适用说明写明："Code reviews may be performed using either manual or automated processes, or a combination of both."（代码审查可以人工或自动化方式进行，或两者结合。）
• 防御逻辑和访问控制攻击。 您的工程方法必须应对针对业务逻辑和访问控制机制等的攻击（要求 6.2.4）。Hunter Agent 正适用于此。
• 保留软件清单。 您需要 "An inventory of bespoke and custom software, and third-party software components"（定制软件、自定义软件及第三方软件组件的清单，要求 6.3.2）。Advanced Security 导出的 SBOM 可以支持这一点。

SonarQube Server Enterprise 包含 PCI DSS 合规报告，截至 2026年10月，Sonar 将其对应到 PCI DSS 4.0 和 3.2.1 版本。它为您的证据提供支持；最终由您的 QSA（负责签核 PCI DSS 的合格安全评估师）决定。

受新加坡监管？也适用 MAS TRM

新加坡金融管理局（MAS）的 技术风险管理指南（Technology Risk Management Guidelines）（2021年1月）涵盖相同的范围：

• 制定编码和审查标准。 金融机构 "should adopt standards on secure coding, source code review and application security testing"（应采用安全编码、源代码审查和应用安全测试标准，第 6.1.1 段）。
• 组合使用测试方法。 它 "may use a mixture of static, dynamic and interactive application security testing"（可组合使用静态、动态和交互式应用安全测试，第 6.1.6 段）。
• 发布前修复重大问题。 问题应被追踪，并且 "Major issues and software defects should be remediated before production deployment"（重大问题和软件缺陷应在生产部署前修复，第 6.1.7 段）。

当新代码仍有重大问题时，用质量门阻止合并，就是证明最后一点确实落实的直接方式。我们的 SonarQube 新加坡页面逐段对照 MAS TRM 与 SonarQube 功能。

常见问题

总结一句：RMiT 源代码审查的关键不在于买哪个工具，而在于每次变更都留下审查记录和独立批准，并让工具自动替您保存这些证据。

资料来源

• Bank Negara Malaysia，Risk Management in Technology (RMiT)，2026年9月25日发布，BNM/RH/PD 028-98。
• Monetary Authority of Singapore，Technology Risk Management Guidelines，2021年1月。
• PCI Security Standards Council，PCI DSS v4.0.1，2024年6月。
• Sonar 文档：合规报告、Advanced Security 和 SonarQube Cloud 区域，2026年10月查阅。

延伸阅读：马来西亚银行和金融机构的 SonarQube 方案，以及 用 SonarQube AI Code Assurance 检查 AI 编写的代码。