3. 静态应用安全测试（SAST）原理与工具选型
静态应用安全测试（SAST）是在不运行程序的前提下，对源代码、字节码或二进制进行安全缺陷检测的技术。它的核心价值在于“左移”——在代码提交、合并甚至编写阶段就发现注入、越权、硬编码密钥、不安全反序列化等问题，从而降低修复成本。理解 SAST 的关键，不是记住某款工具的命令，而是理解它如何“看懂”代码：从词法、语法到语义，再到跨函数、跨文件的数据流与污点传播，最后通过规则引擎把可疑模式判定为缺陷。
一、从字符到语义：SAST 的四层分析能力
SAST 工具首先要把源代码变成可分析的结构。这个过程通常分为四层：
- 词法分析（Lexical Analysis）：将字符流切分为 token，例如关键字、标识符、运算符、字符串字面量。它只能识别“看起来像什么”，例如发现
password = "123456"中的硬编码字符串，但无法判断该变量是否真的被用于认证。 - 语法分析（Syntax Analysis）：根据语言文法把 token 组织成抽象语法树（AST），识别函数定义、条件分支、循环、赋值等结构。语法分析能发现明显的危险调用，例如
Runtime.getRuntime().exec(userInput)，但仍不追踪userInput从何而来。 - 语义分析（Semantic Analysis）：在 AST 之上建立符号表、类型信息、作用域和控制流图（CFG），理解变量绑定、函数调用关系、分支可达性。语义分析是区分“同名变量”和“真实传播”的关键。
- 数据流与污点分析（Data Flow / Taint Analysis）：把外部输入标记为“污点源”，把危险操作标记为“汇聚点”，沿赋值、参数传递、返回值、容器存取等路径传播污点，若污点未经净化到达汇聚点，则报告漏洞。这是 SAST 检测注入类漏洞的核心机制。
下面这张图展示了从源码到漏洞判定的完整信号链，重点体现污点从 Source 到 Sink 的传播与净化分支：
二、规则引擎如何判定漏洞
规则引擎是 SAST 的“大脑”。一条完整的污点规则通常包含五个要素：Source 定义（哪些 API 产生外部输入）、传播规则（赋值、字符串拼接、集合存取、函数参数如何传递污点）、Sanitizer 白名单（哪些函数能净化污点，如预编译、HTML 编码、路径规范化）、Sink 特征（哪些 API 危险，如 Statement.execute、Runtime.exec、File 构造）、严重级别与置信度。规则引擎会先做模式匹配快速筛选，再用数据流约束验证可达性，最后结合语义条件排除误报。
以 Java 为例，一条简化的 SQL 注入规则可以这样描述：
rule: java-sql-injection
source:
- javax.servlet.http.HttpServletRequest.getParameter
- javax.servlet.http.HttpServletRequest.getHeader
propagators:
- java.lang.String.concat
- java.lang.StringBuilder.append
- 赋值、方法参数、返回值
sanitizers:
- java.sql.PreparedStatement.setString
- org.owasp.encoder.Encode.forSql
sink:
- java.sql.Statement.execute
- java.sql.Statement.executeQuery
severity: HIGH
confidence: MEDIUM当工具发现 String name = request.getParameter("name"); 后，name 被标记为污点；若它经过 StringBuilder.append 拼入 SQL 并传给 Statement.executeQuery，且中间没有经过 PreparedStatement.setString，则报告高危 SQL 注入。若代码改为 PreparedStatement 参数化查询，污点在 setString 处被净化，规则不报告。这就是“数据流 + 净化判断”的实际判定逻辑。
三、主流 SAST 工具对比与适用场景
工具选型不能只看“谁报得多”，而要看语言支持、分析深度、集成方式、误报率和团队工作流。下表给出常见工具的能力对比，参数为教学示例，实际以官方文档和实测为准：
| 工具 | 核心分析方式 | 语言支持 | 集成方式 | 适用场景 |
|---|---|---|---|---|
| SonarQube | 词法/语法 + 部分数据流 | Java、C#、JS、Python、Go 等 | CI 插件、Scanner、Web 平台 | 代码质量与安全统一门禁，适合中大型团队 |
| Semgrep | AST 模式匹配 + 轻量数据流 | 多语言，规则可自定义 | CLI、CI、IDE 插件 | 快速自定义规则、DevSecOps 左移、轻量扫描 |
| CodeQL | 语义数据库 + 全局数据流 | Java、C/C++、C#、JS、Python、Go | GitHub Actions、CLI | 深度漏洞挖掘、变体分析、安全研究 |
| Fortify SCA | 跨文件数据流 + 语义分析 | 主流企业语言 | CI、IDE、审计平台 | 合规审计、强监管行业、深度扫描 |
| Checkmarx | 数据流 + 污点分析 | 主流企业语言 | CI、IDE、API | 企业级集中管理、多团队协作 |
选型时建议按以下顺序判断：第一，语言与框架覆盖是否匹配现有技术栈；第二，分析深度是否满足合规或高危漏洞检测要求；第三，集成成本是否能在 CI 中稳定运行并控制扫描时长；第四，误报治理是否支持基线、抑制、自定义规则；第五，团队能力是否能维护规则和解读数据流路径。对于快速迭代的互联网团队，Semgrep + SonarQube 组合往往能兼顾速度与覆盖面；对于金融、政企等强合规场景，CodeQL 或 Fortify 的深度数据流能力更合适。
总结来说，SAST 的检测能力由“分析深度”和“规则质量”共同决定。词法、语法、语义分析解决“代码是什么结构”，数据流与污点分析解决“危险数据能否到达危险操作”，规则引擎解决“如何判定和分级”。工具选型则应回到团队的语言栈、合规要求、CI 流程和误报治理能力上，而不是单纯比较漏洞数量。