2. 代码安全审查的标准与合规基线

代码安全审查不能只凭审查者个人经验判断“这段代码危不危险”。要让审查结论可复现、可交付、可审计，必须把审查活动挂接到一套外部公认的标准与合规基线上。本节要解决的核心问题是：OWASP Top 10、CWE Top 25、ISO 27001、网络安全等级保护、PCI DSS 这几类标准各自“管什么、对代码审查提出什么要求”，以及如何据此界定审查范围并留存证据。

一、五类标准的定位差异

这些标准并不在同一层级，混用会导致审查范围失控。可以按“威胁清单—缺陷分类—管理体系—合规制度—行业规范”来理解：

• OWASP Top 10：面向 Web 应用的风险类别清单，描述“哪类风险最常见”，如失效的访问控制、注入、加密机制失效等。它回答“该重点查什么风险”，但不给出具体缺陷编号。
• CWE Top 25：面向软件缺陷类型的分类体系，如 CWE-79 跨站脚本、CWE-89 SQL 注入、CWE-798 硬编码凭据。它回答“这个漏洞属于哪一类根因”，是审查条目和工具规则映射的公共语言。
• ISO 27001：信息安全管理体系标准，关注组织是否建立并运行了受控的开发与变更流程，如安全需求、代码评审、变更管理、日志留存。它不直接规定“查哪一行代码”，而是要求“有制度、有记录、可追溯”。
• 网络安全等级保护（等保2.0）：国家合规制度，在安全计算环境、应用和数据安全等层面提出要求，如身份鉴别、访问控制、安全审计、入侵防范，并强调测评与整改闭环。
• PCI DSS：支付卡行业的强制性规范，对持卡人数据环境（CDE）提出要求，如要求 6.2.4 规定开发人员每年接受安全编码培训、6.3.2 要求对定制软件进行代码评审以识别代码级漏洞，并强调变更后重新评审。

关键结论是：OWASP 与 CWE 决定“查什么”，ISO 27001 与等保决定“怎么管、怎么留证”，PCI DSS 决定“在支付场景下必须做到什么程度”。审查方案应把三者叠加，而不是任选其一。

二、从标准到审查条目：映射方法

标准本身不能直接执行，必须转成可操作的审查条目。常用做法是“风险类别 → 缺陷类型 → 代码位置 → 验证方法”四级映射。以登录功能为例：

映射完成后，审查条目就同时具备了“合规出处”和“技术判据”，评审结论才能被审计方接受。

三、合规驱动的审查范围界定

范围界定要回答三个问题：审哪些系统、审哪些代码、审到什么深度。建议按以下顺序收敛：

1. 系统定级与数据分级：等保三级系统与一般内部系统，审查深度不同；涉及个人敏感信息或持卡人数据的模块必须纳入。
2. 判定是否落入 PCI DSS 范围：只要代码路径会接触、传输或影响持卡人数据（含认证、授权、日志、批处理），即属于 CDE 相关代码，必须执行代码评审。
3. 按语言与框架裁剪条目：Java 项目重点查反序列化、表达式注入；前端项目重点查 XSS、DOM 型漏洞；C/C++ 项目补充内存安全类 CWE。
4. 按风险优先级排序：对外暴露的接口、认证授权、支付与资金、文件上传下载、第三方组件引入点优先。

四、证据留存：让审查结论可审计

ISO 27001 与等保测评都强调“可追溯”，PCI DSS 更是明确要求保留评审结果。证据留存应至少覆盖以下要素，并与代码版本绑定：

审查记录编号: CR-2024-0137
代码基线:     commit 9f3c1ab (release/2.4.0)
审查范围:     payment-service, auth-service
审查条目:     OWASP A01/A03/A07, CWE-89/284/798
发现问题:
  - CWE-89  SQL注入  PaymentDao.java:142  严重
  - CWE-798 硬编码密钥  SignUtil.java:33   严重
  - CWE-284 越权查询  OrderApi.java:88    中
整改状态:     已修复并复测通过 (2024-06-18)
审查人/复核人: 张某 / 李某

证据链的关键是“问题—位置—标准出处—整改—复测”五要素齐全。缺少标准出处，无法证明合规；缺少复测记录，无法证明闭环；缺少版本基线，无法证明审查针对的是上线代码。

五、落地建议

把上述内容固化为组织内的《代码安全审查基线表》：左侧列合规来源（OWASP/CWE/等保条款/PCI DSS 要求），中间列审查条目与判据，右侧列证据字段与责任人。每次评审按基线表逐条勾选，未覆盖项需说明理由。这样，代码审查就从“个人经验活动”升级为“可度量、可审计、可持续改进的合规工程活动”。