安全代码审查（Secure Code Review）实战指南：基于 OWASP Cheat Sheet Series 的方法论、检查清单与工具集成手册

安全代码审查（Secure Code Review）是通过人工逐行审阅源代码、识别自动化工具常常漏掉的逻辑性、数据流与上下文相关的安全缺陷的过程。本指南以 OWASP Cheat Sheet Series 仓库中 cheatsheets/Secure_Code_Review_Cheat_Sheet.md 为骨架，结合仓库内的写作规范、CI/链接校验脚本与配套速查表，完整覆盖从审查类型选择、审查流程设计、常见漏洞模式识别、逐项检查清单，到编辑器/命令行/SAST 工具协同、SDLC 集成的全部环节。读完本文，你将具备组织基线审查与差异（Diff）审查、按数据流追踪漏洞、输出标准化漏洞报告，并将安全审查嵌入团队日常开发流程的完整实操能力。

什么是安全代码审查

安全代码审查是手动检查源代码以发现自动化工具经常遗漏的安全漏洞的过程。它通过分析应用逻辑、数据流向和实现细节，来识别那些需要人类专业知识和上下文理解才能发现的安全缺陷。

与自动化安全测试互补

人工代码审查（Manual Code Review）是对自动化安全测试工具（SAST/DAST）的补充，其价值集中在人类分析最有优势的领域：

• 业务逻辑校验：多步流程中的状态校验、金额计算、权限判定等，自动化工具难以建立业务语义模型；
• 复杂安全实现：自研的加密协议封装、OAuth 流程、权限模型等跨组件交互逻辑；
• 上下文相关漏洞：依赖具体业务规则才能确认的风险（如"优惠券能否叠加使用"）。

自动化工具可以先行标记可疑区域（potential areas of concern），但核心分析仍然依赖人类判断与领域专业知识。这正是本仓库的定位所在——README.md 明确该项目聚焦于"为构建者提供良好的安全实践"，Markdown 文件是官方站点的工作源文档。

安全审查与功能审查的区别

安全聚焦型审查（Security-Focused Review）与常规功能代码审查不同，它专门针对以下安全关切：

• 输入验证是否完整；
• 认证（Authentication）机制是否可被绕过；
• 授权（Authorization）控制是否存在越权；
• 加密实现是否正确使用；
• 潜在攻击向量是否可被利用。

两种审查类型：基线审查与差异审查

审查类型	覆盖范围	典型适用场景
基线审查（Baseline Reviews）	全量代码库，彻底全面	新应用或重大版本发布、遗留系统接入、合规要求、安全事件后分析
差异审查（Diff-Based Reviews）	仅聚焦代码变更	Pull Request 与提交、日常开发流程、功能完成、持续安全验证

本速查表为这两种审查方法均提供了可落地的操作指引。在仓库实践中，差异审查与 CONTRIBUTING.md 描述的贡献流程天然对应：每次 Pull Request 即是一次"代码变更集"的安全审查单元，仓库要求审查者核对 CI 校验结果，确保变更不引入新问题。

审查方法论：准备与执行

审查前的准备

所有审查类型通用：

• 理解应用架构与业务需求；
• 收集威胁模型和既往安全发现（Threat Models 与历史 findings）；
• 识别关键资产和高风险函数；
• 复核安全需求与相关文档。

基线审查额外准备：

• 绘制完整的应用边界与依赖关系图；
• 分析整体安全架构；
• 复盘安全事件历史；
• 审计全部第三方库（依赖项审查）。

差异审查额外准备：

• 识别被修改的文件及受影响的组件；
• 评估变更对现有安全控制的影响；
• 理解变更目的（是修 bug、加功能还是重构？）；
• 对高风险修改（涉及认证、支付、权限的改动）优先排序。

审查执行流程

基线审查步骤：

1. 架构审查：识别安全反模式（anti-patterns），如全局信任边界缺失、单点认证旁路；
2. 入口点分析与输入验证：枚举所有外部输入入口（HTTP 参数、文件上传、消息队列、环境变量）；
3. 认证与授权验证：确认每个受保护资源都有对应的认证/授权检查；
4. 数据流追踪：从源头到汇点逐段跟踪敏感数据；
5. 业务逻辑分析：核对工作流状态机、金额计算、配额逻辑；
6. 加密实现审查：核对算法选择、密钥生命周期、随机数来源；
7. 错误处理验证：确认异常不会泄露堆栈、SQL 语句或内部路径；
8. 配置与部署审查：核对生产配置、环境隔离、默认值安全。

差异审查步骤：

1. 分析变更对现有安全控制的影响（例如修改认证过滤器是否会引入绕过）；
2. 识别新增攻击向量（新端点、新输入格式、新集成）；
3. 验证变更涉及的安全信任边界是否仍被正确守护；
4. 检查新增集成（第三方 API、新库、新存储）的安全性；
5. 确保无安全回归（security regression）；
6. 应用相关安全模式（参数化查询、输出编码、最小权限等）。

混合策略

• 风险驱动调度：对高风险组件做基线审查，对常规变更做差异审查；
• 增量基线扩展：在多个开发周期中逐步扩大基线审查覆盖范围；
• 触发式升级：当差异审查发现重大安全隐患时，升级为基线式全面审查。

常见漏洞模式：人工审查要盯住什么

以下漏洞模式与仓库内对应的专题速查表一一对应，审查时可直接跳转获取深度处置方案。

输入验证漏洞

检查服务端验证是否缺失、净化（sanitization）是否不当、输入过滤是否薄弱。客户端校验可被绕过，必须依赖服务端。详见 Input Validation Cheat Sheet。

注入类漏洞

SQL 注入（SQL Injection）：

• 在数据库查询中查找字符串拼接（string concatenation）；
• 检查不安全的查询构造方式（如 ORM 原生 SQL、动态拼接 WHERE 子句）；
• 确认所有查询均使用参数化查询（PreparedStatement / 参数绑定）或存储过程。

详见 SQL Injection Prevention Cheat Sheet。

跨站脚本（XSS）：

• 审查输出编码是否按上下文区分（HTML、JavaScript、CSS、URL、属性值）；
• 检查 DOM 操作是否直接渲染用户输入；
• 确认用户输入渲染路径上不存在 innerHTML、document.write 等危险写入点。

详见 Cross Site Scripting Prevention Cheat Sheet。

路径遍历（Path Traversal）：

• 检查不安全的文件路径构造（如直接拼接用户输入到路径）；
• 验证目录遍历防护（../ 序列、绝对路径注入）；
• 检查上传文件的重命名与存储目录策略。

详见 File Upload Cheat Sheet。

命令注入（Command Injection）：

• 识别直接使用用户输入执行命令的代码（system()、exec()、Runtime.exec()、子进程调用）；
• 检查不安全的系统调用与 shell 元字符过滤；
• 优先采用参数化 API 或白名单化的命令执行。

详见 OS Command Injection Defense Cheat Sheet。

NoSQL 注入：

• 检查 NoSQL 查询构造方式（如 MongoDB 操作符注入 $where、$gt）；
• 确认参数绑定与查询白名单机制。

详见 NoSQL Security Cheat Sheet。

认证与会话管理漏洞

审查认证机制、会话令牌生成方式与用户凭证处理：

• 会话令牌是否足够随机（≥128 bits 熵）；
• 登录、注销、超时、密码重置等生命周期钩子是否安全；
• 凭证是否以明文传输或存储。

详见 Authentication Cheat Sheet 与 Session Management Cheat Sheet。

访问控制漏洞

审查授权检查、基于角色的访问控制（RBAC）与提权防护：

• 每个敏感操作是否有独立的服务端授权校验；
• 是否默认拒绝（deny by default）；
• 是否存在水平越权（IDOR）与垂直越权路径。

详见 Authorization Cheat Sheet。

反序列化漏洞

不安全反序列化（Insecure Deserialization）：

• 检查对不可信数据执行反序列化操作的代码；
• 警惕对象注入（Object Injection）与 gadget chain 利用；
• 优先使用类型白名单或纯数据格式（JSON 而不带类型魔术）。

详见 Deserialization Cheat Sheet。

XML 外部实体（XXE）：

• 审查 XML 解析器配置（是否禁用 DTD、外部实体、参数实体）；
• 检查外部实体处理路径，防止文件读取、SSRF 与 DoS（如 Billion Laughs）。

详见 XML External Entity Prevention Cheat Sheet。

加密实现缺陷

审查加密算法选型、密钥管理与加密实现：

• 是否误用弱算法（MD5、SHA-1、DES、ECB 模式）做安全敏感操作；
• 密钥是否硬编码、是否定期轮换；
• 随机数是否来自密码学安全随机源（CSPRNG）。

详见 Cryptographic Storage Cheat Sheet。

审查技术：从代码模式到数据流

代码模式分析（Code Pattern Analysis）

聚焦高风险代码模式，在代码库中定位这些模式出现的所有位置：

• 输入处理与验证函数；
• 数据库查询构造与 ORM 用法；
• 文件操作与路径处理；
• 认证与会话管理逻辑；
• 授权与访问控制检查；
• 加密操作与密钥管理；
• 错误处理与日志记录机制；
• 配置加载与环境变量读取。

数据流分析（Data Flow Analysis）

按"源头 → 处理 → 汇点 → 边界"四段追踪数据：

1. 识别源头（Sources）：用户输入、文件上传、API 调用、数据库读取、环境变量；
2. 跟踪处理（Processing）：验证、转换、业务逻辑、缓存；
3. 检查汇点（Sinks）：数据库查询、文件写入、输出渲染、日志记录、外部 API 调用；
4. 验证边界（Boundaries）：信任边界处的输入验证与输出编码；
5. 信任区（Trust Zones）：每次跨越信任边界都必须核验安全控制是否生效；
6. 数据分类（Data Classification）：确保敏感数据（PII、凭证、支付信息）获得相应级别的保护。

基于威胁模型的审查（Threat-Based Review）

将审查工作与常见攻击模式对齐：

• OWASP Top 10：聚焦 Web 应用最常见风险；
• STRIDE 模型：Spoofing（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄露）、DoS（拒绝服务）、Elevation（提权）；
• 攻击树（Attack Trees）：映射穿透应用的可能攻击路径；
• 滥用用例（Abuse Cases）：从攻击者视角思考功能如何被误用——可结合 Abuse Case Cheat Sheet 系统化产出；
• 安全控制验证：核验纵深防御（Defense-in-Depth）是否真正落地。

业务逻辑审查（Business Logic Review）

分析应用工作流时关注：

• 状态管理与状态迁移校验（例如：订单必须经历"待支付→已支付→已发货"合法迁移）；
• 竞态条件与并发问题（如并发下单、库存超卖）；
• 事务完整性与回滚机制；
• 资源限制与配额执行（速率限制、上传大小、调用次数）；
• 工作流每一步的授权校验；
• 工作流绕过机会（直接调用 API 跳过前置步骤）。

审查检查清单：逐项可勾选的落地清单

输入验证检查清单

• [ ] 服务端验证：无论客户端是否有校验，所有输入都必须在服务端校验
• [ ] 白名单校验：输入验证优先使用白名单（allowlist）而非黑名单（blocklist）
• [ ] 输出编码：按上下文选择编码（HTML、JavaScript、CSS、URL、SQL）
• [ ] 文件上传安全：基于内容的验证、大小限制、安全存储
• [ ] SQL 注入防护：使用参数化查询或存储过程
• [ ] 长度限制：强制执行输入长度限制
• [ ] 字符处理：特殊字符与 Unicode 被正确处理
• [ ] 错误消息：错误响应不泄露敏感信息

认证与会话管理检查清单

• ] 密码安全：使用强哈希算法并加盐（详见 [Password Storage Cheat Sheet）
• [ ] 账户保护：设置合理阈值的锁定机制
• [ ] 会话管理：安全令牌生成（熵 ≥128 bits）
• [ ] 会话生命周期：注销/超时时正确失效会话
• [ ] 重新认证：敏感操作要求重新认证
• ] 多因素认证：高风险账户启用 MFA（详见 [Multifactor Authentication Cheat Sheet）
• ] 密码重置：安全、限时的重置机制（详见 [Forgot Password Cheat Sheet）
• [ ] 会话安全：Cookie 设置 HttpOnly、Secure、SameSite 属性
• [ ] 并发会话：设置合理限制并监控

授权检查清单

• [ ] 服务端强制：所有访问控制都在服务端强制实施
• [ ] 故障安全默认：默认拒绝（deny）访问策略
• ] IDOR 防护：资源访问有正确授权（详见 [Insecure Direct Object Reference Prevention Cheat Sheet）
• [ ] 函数级控制：管理功能受到妥善保护
• [ ] 角色校验：角色分配不可被篡改
• [ ] 提权防护：阻止水平与垂直越权
• [ ] 集中决策：访问控制逻辑集中化（避免分散在各处而遗漏）
• [ ] 认证后检查：认证之后仍要核验授权（认证≠授权）

加密检查清单

• [ ] 强算法：使用现代算法（AES-256、RSA-2048+、ECDSA P-256+）
• ] 密钥管理：正确的密钥生成、存储与轮换（详见 [Key Management Cheat Sheet）
• [ ] 证书校验：包含主机名验证在内的完整校验
• [ ] 随机数生成：使用密码学安全随机数生成器
• [ ] 数据保护：静态数据加密（at rest）与传输加密（in transit）
• [ ] IV/Nonce 处理：唯一且不可预测的初始化向量
• [ ] 库维护：加密库保持更新
• [ ] 侧信道防护：考虑时序攻击等侧信道风险

业务逻辑检查清单

• [ ] 工作流完整性：多步骤流程有正确的状态校验
• [ ] 竞态条件防护：并发操作有同步机制
• [ ] 事务原子性：有正确的回滚与一致性机制
• [ ] 资源限制：实现速率限制与资源配额
• [ ] 业务规则强制：无法通过直接 API 访问绕过业务规则

配置与部署检查清单

• [ ] 安全默认值：安全优先的默认配置
• [ ] 环境隔离：开发/测试/生产环境正确隔离
• ] 密钥管理：无硬编码密钥，正确的密钥存储与轮换（详见 [Secrets Management Cheat Sheet）
• ] 错误处理：优雅处理错误、不泄露信息（详见 [Error Handling Cheat Sheet）
• ] 日志安全：不记录敏感数据、日志受保护（详见 [Logging Cheat Sheet）
• ] 安全响应头：配置合适的 HTTP 安全头（详见 [HTTP Headers Cheat Sheet）
• ] TLS 配置：强密码套件与协议版本（详见 [Transport Layer Security Cheat Sheet）
• ] 依赖管理：库保持更新、无已知漏洞（详见 [Vulnerable Dependency Management Cheat Sheet）

安全监控检查清单

• [ ] 安全事件：记录认证失败、授权违规
• [ ] 异常检测：监控异常模式与行为
• [ ] 审计追踪：敏感操作有完整审计日志
• [ ] 实时告警：关键安全事件触发即时通知
• [ ] 日志完整性：日志防篡改、防未授权访问
• [ ] 事件响应：有明确的安全事件处理流程

工具与技术：人工审查的武器库

代码编辑器与安全扩展

编辑器	推荐安全相关扩展
Visual Studio Code	ESLint、SonarLint
IntelliJ IDEA	SpotBugs、SonarLint
Eclipse	安全插件（如 Find Security Bugs）
Vim/Neovim	安全 linter（如 vim-ale 配置安全规则集）

命令行模式检测

以下命令可在代码库中快速定位高风险模式，作为人工审查的"第一轮粗筛"：

# 查找硬编码密钥
grep -ri "password\s*=\|api_key\s*=\|secret\s*=" source/

# 查找危险函数
grep -r "eval(\|exec(\|innerHTML\|document\.write" source/

# 查找潜在注入点（SQL 拼接模式）
grep -r "SELECT.*+\|executeQuery.*+" source/

人工审查的聚焦领域

人类专家的独特优势：

• 业务逻辑缺陷：需要领域理解才能识别的复杂工作流与状态管理问题；
• 上下文相关漏洞：依赖特定业务规则的安全问题；
• 授权逻辑：复杂权限模型与访问控制实现；
• 竞态条件：并发操作中的时序型漏洞；
• 加密误用：加密原语与协议的正确实现；
• 架构安全：高层设计缺陷与安全反模式。

人工分析技术：

• 代码路径追踪：沿执行路径穿越复杂业务逻辑；
• 状态分析：理解应用状态迁移与校验；
• 信任边界映射：识别并分析安全控制点；
• 威胁建模集成：将威胁模型应用到具体代码实现；
• 攻击场景模拟：在脑中模拟穿透代码的攻击路径。

自动化工具集成：让工具为人效劳

支撑人工审查的自动化能力：

• SAST 工具分流（Triage）：用自动化发现结果指导人工审查的优先级；
• 依赖扫描：识别需要人工评估的脆弱库；
• 代码质量指标：把人工精力投向复杂或高频变更的代码；
• 模式检测：用工具高亮潜在安全反模式供人工分析。

工具集成策略：

• 审查前扫描：人工审查前先跑自动化工具以发现明显问题；
• 互补分析：用工具发现引导更深入的人工调查；
• 误报过滤：用人类判断验证自动化发现（这是人工审查不可替代的价值）；
• 覆盖缺口：把人工精力集中于自动化工具无法有效分析的领域。

安全度量指标：

• 人工审查覆盖率：关键代码路径被人工审查的百分比；
• 发现质量：有效安全问题占全部发现的比例（衡量误报过滤效果）；
• 审查效率：投入的审查时间与产生的安全价值之比；
• 趋势分析：安全态势随时间是否改善。

文档模板：让发现可追踪、可闭环

漏洞发现报告模板：

Title: [Vulnerability Type] in [Component]
Severity: [Critical/High/Medium/Low]
CWE: [CWE Number and Name]
Location: [File:Line or Function]
Description: [Detailed explanation of the vulnerability]
Impact: [Security implications and potential attack scenarios]
Reproduction: [Steps to reproduce or proof of concept]
Recommendation: [Specific fix guidance with code examples]
References: [CWE links, OWASP references, vendor documentation]
Status: [Open/In Progress/Fixed/Accepted Risk]
Assignee: [Developer responsible for fix]
Due Date: [Target fix date]

审查总结模板：

Review Summary
==============
Application: [Application Name]
Version: [Version/Commit Hash]
Reviewer(s): [Names]
Review Date: [Date]
Scope: [Files/Components Reviewed]

Findings Summary:
- Critical: [Count]
- High: [Count]
- Medium: [Count]
- Low: [Count]
- Informational: [Count]

Key Recommendations:
1. [Priority recommendation]
2. [Priority recommendation]
3. [Priority recommendation]

Overall Risk Assessment: [Low/Medium/High/Critical]

与 SDLC 的集成：把安全审查嵌入开发生命周期

审查时机

基线审查的集成点：

• 项目启动：对既有代码库做全面安全评估；
• 重大发布：重要版本发布前做完整安全审查；
• 架构变更：基础设计变化时做全量审查；
• 合规周期：按监管要求周期性全面审查；
• 安全事件：安全漏洞/事件后彻底复盘；
• 遗留系统接入：将现有应用纳入安全开发实践时的初始评估。

差异审查的集成点：

• Pull Request：作为标准 PR 流程的一部分做安全聚焦审查；
• 提交前钩子（Pre-commit Hooks）：开发者提交时运行轻量安全检查；
• 功能完成：用户故事或功能完成后做安全审查；
• Sprint 评审：定期评估迭代交付物的安全影响；
• 热修复审查：紧急修复的快速安全评估；
• 持续集成：基于代码变更自动触发安全审查。

混合方式：

• 基于风险的调度：高风险组件用基线审查，常规变更用差异审查；
• 增量基线更新：跨多个开发周期逐步扩大基线覆盖；
• 触发式升级：发现重大安全隐患时从差异审查升级为基线审查。

仓库本身即是"将质量检查嵌入 PR 流程"的样板：package.json 定义了 npm run lint-markdown 与 npm run lint-terminology 两类校验脚本，npm run link-check 会对全部速查表执行死链检测，scripts/Apply_Link_Check.sh 遍历 cheatsheets/ 下所有 Markdown 文件并统计 ERROR: 数量，任一死链都会导致校验失败。这相当于在"文档即代码"场景下的持续安全/质量校验——审查结论、格式规范与链接有效性在合并前就被自动守住了。对于 CI/CD 场景下的自动化安全测试集成，可进一步参考 CI CD Security Cheat Sheet。

团队协作

角色分工：

• 安全审查员（Security Reviewers）：执行分析并提供修复指导；
• 开发者（Developers）：实施修复并遵循安全编码实践；
• 安全代言人（Security Champions）：在安全团队与开发团队之间架桥，推广安全实践。

最佳实践：

• 使用标准化检查清单与模板（即上文两套可勾选清单与报告模板）；
• 维护常见问题知识库；
• 跟踪审查有效性指标；
• 定期提供安全培训；
• 与既有开发工作流集成（而不是另起炉灶）。

仓库自身的协作规范印证了这一点：CONTRIBUTING.md 要求每个 Pull Request 聚焦单文件、作者需在合并前用 markdown-link-check -c .markdownlinkcheck.json <a href="https://link.gitcode.com/i/f8962e484d8851d2af7fb037644f442a" target="_blank">MD_FILE] 自检死链，并在 VSCode 中通过 markdownlint 插件实时消除格式告警（见 [assets/README_PluginWarningUI.png 的插件告警示意）——这本质上是把"审查前置、工具辅助、人机协作"的实践用在了文档生产线上。同时，仓库的写作规范 GUIDELINE.md 也强调"实用优先于理论、架构指导优先于代码片段、意见明确"——这正是高质量安全代码审查产出物（修复建议）应具备的品质。

高级审查技术

竞态条件分析（Race Condition Analysis）

聚焦 TOCTOU（Time-of-Check vs Time-of-Use，检查时与使用时的时差） 漏洞。典型模式：先检查文件存在/权限/余额，再执行操作，中间被并发请求改变状态。审查要点：

• 检查-使用之间是否有锁或原子操作；
• 文件操作是否使用原子化 API（如 open(O_EXCL)、rename）；
• 余额/库存扣减是否使用条件更新（UPDATE ... WHERE stock >= ?）而非"读-改-写"。

业务逻辑分析（Business Logic Analysis）

分析工作流时审查：

• 状态迁移与校验；
• 绕过某步骤或校验的机会（如直接 POST 到中间步骤接口）；
• 每一步的校验是否充分；
• 失败时的回滚机制与清理逻辑；
• 并发访问下的行为；
• 边界条件与错误场景（金额为 0、负数、超大数据量）。

安全架构审查（Security Architecture Review）

审查架构模式是否一致地强制安全控制：

• 安全控制是否集中（集中式 PDP/PEP 模式）而非散落各处；
• API 安全控制是否完备（认证、限流、输入校验、输出编码）；
• 微服务/服务网格场景下信任边界是否清晰（可参考仓库中 cheatsheets_draft/ 目录下的授权与身份传播模式草稿，如 cheatsheets_draft/Authorization_Patterns_Cheat_Sheet.md）。

内存安全（Memory Safety）

针对 C/C++ 等非托管语言代码：

• 缓冲区管理：检查 strcpy、sprintf 等非边界检查函数；
• 整数溢出防护：长度计算、大小比较中的整数溢出；
• 资源限制：文件描述符、内存分配、连接数上限。

相关资源导航

配套速查表（仓库内闭环阅读路径）

方法论基础：

• Threat Modeling Cheat Sheet
• Abuse Case Cheat Sheet
• Attack Surface Analysis Cheat Sheet
• Secure Product Design Cheat Sheet

漏洞专题处置：

• Mass Assignment Cheat Sheet
• Insecure Direct Object Reference Prevention Cheat Sheet
• Cross-Site Request Forgery Prevention Cheat Sheet
• Server Side Request Forgery Prevention Cheat Sheet
• Unvalidated Redirects and Forwards Cheat Sheet
• Denial of Service Cheat Sheet

审查产出与持续改进：

• CI CD Security Cheat Sheet（CI 中的自动化安全测试）
• Authorization Regression Testing Cheat Sheet 与 Authorization Testing Automation Cheat Sheet（授权回归与自动化验证，可直接支撑审查发现的回归防护）

仓库工程资产

• templates/New_CheatSheet.md：新建速查表的官方模板，其"Introduction / Main Sections / References"结构同样可作为安全审查报告的章节骨架；
• scripts/Generate_CheatSheets_TOC.py：自动扫描 cheatsheets/ 生成目录页的脚本——安全审查团队可借鉴此类"全量枚举 + 排序 + 汇总"的思路来盘点代码库入口；
• markdown-link-check-config.json：死链检查的忽略规则与 HTTP 头配置，展示了"链接/引用完整性校验"的工程化落地。

适用前提说明：本指南以当前仓库内 cheatsheets/Secure_Code_Review_Cheat_Sheet.md 的内容为准。文中命令行示例（grep 模式检测）适用于 Unix/Linux 类环境，SAST 工具的具体能力、检查清单的覆盖度应以你实际使用的工具链与合规要求为准。安全代码审查的本质是"人机协作、上下文驱动"：自动化工具负责广度，人工审查负责深度，二者结合才能构成完整的应用安全防线。