1. 代码安全审查工程导论
软件代码安全审查，是指在软件开发生命周期中，以源代码、配置文件和构建脚本为直接对象，通过人工分析、规则匹配、数据流追踪与工具辅助等手段，系统性地发现安全缺陷、验证风险可利用性并推动修复的工程活动。它关注的不是"程序能不能跑通"，而是"程序在恶意输入、越权访问、异常时序下会不会被利用"。与渗透测试从外部黑盒探测不同，代码安全审查直接面对实现细节，能够定位到具体文件、函数、行号与变量传播路径，因此常被视为安全左移中最具确定性的一环。
代码安全审查的目标可以拆成四层：第一层是发现缺陷，识别注入、越权、反序列化、硬编码密钥、路径穿越等典型问题；第二层是判定可利用性，区分"看起来危险"与"确实可被外部触达并造成影响"；第三层是推动修复与验证，给出可落地的修改建议并回归确认；第四层是沉淀工程能力，把个案转化为规则、门禁、培训与度量，使同类问题不再重复出现。只做第一层，审查就退化为"扫一遍报告"；四层贯通，才称得上工程化。
在 SDL 与 DevSecOps 中的位置
在微软 SDL 的经典框架中，安全活动被嵌入需求、设计、实现、验证、发布、响应各阶段。代码安全审查主要落在"实现"与"验证"两个阶段：实现阶段通过编码规范、静态分析、代码评审拦截缺陷；验证阶段通过人工审计与工具复核确认高风险模块。在 DevSecOps 中，审查进一步被拆解为可自动化的流水线节点——提交时做增量扫描，合并请求时做差异审查，发布前做全量基线与依赖审计。二者的差别在于：SDL 强调阶段化的强制门禁，DevSecOps 强调持续、快速、可度量的反馈闭环。代码安全审查工程正是把两者衔接起来的方法论与工具链。
审查与测试的区别
很多团队把代码安全审查和渗透测试混为一谈，结果要么用测试报告代替审查结论，要么用审查清单代替验证。两者的核心差异在于观察视角与证据形态。渗透测试是黑盒或灰盒，从攻击者视角构造请求，证据是"某个接口返回了不该返回的数据"；代码安全审查是白盒，从实现者视角追踪数据流，证据是"第 87 行的 SQL 语句由第 42 行的用户输入直接拼接，且未经过滤函数"。前者证明"能被攻破"，后者解释"为什么会被攻破、还有哪些同类入口"。在工程实践中，二者应互补：审查发现缺陷并修复，测试验证修复是否有效、是否存在遗漏的利用链。
| 维度 | 代码安全审查 | 安全测试（渗透/DAST） |
|---|---|---|
| 对象 | 源代码、配置、构建脚本 | 运行中的服务与接口 |
| 视角 | 白盒，实现者视角 | 黑盒/灰盒，攻击者视角 |
| 证据 | 文件、行号、数据流路径 | 请求、响应、利用效果 |
| 覆盖 | 可覆盖未触发分支与内部逻辑 | 仅覆盖可达路径 |
| 时机 | 编码与合并阶段即可介入 | 通常在可运行环境部署后 |
| 产出 | 缺陷清单、修复建议、规则沉淀 | 漏洞报告、风险评级、复测结论 |
工程化审查的核心要素与能力模型
把审查从"个人经验"变成"工程能力"，需要五个要素同时到位：标准（编码安全规范与审查清单）、工具（SAST、SCA、密钥扫描、IAST 等）、流程（何时审、谁审、如何闭环）、度量（缺陷密度、修复时长、逃逸率）、人（具备安全思维的开发与审查者）。缺任何一项，审查都会退化为一次性活动。
能力模型可分三级。初级审查者能按清单识别常见缺陷，例如硬编码口令、未校验的重定向、日志打印敏感信息；中级审查者能追踪跨函数、跨文件的数据流，判断反序列化链是否可被外部触达，并能编写自定义规则；高级审查者能设计审查策略、建立威胁模型与审查范围的映射、用度量数据驱动改进，并在架构层面提出消减方案。对大多数团队而言，目标不是人人成为高级审查者，而是让初级能力成为开发者的基线，让中级能力覆盖高风险模块，让高级能力集中在安全团队与架构评审环节。