SAST能发现SQL注入因其通过AST分析和污点追踪识别用户输入未经净化流入数据库执行函数，但存在漏报（如二次注入、MyBatis ${}拼接）和误报（如日志打印），需正确配置污点分析、可信入口与安全调用排除，并辅以人工验证和DAST交叉确认。
为什么SAST能发现SQL注入，但不能全信？
SAST工具确实能识别大部分硬编码拼接SQL的场景，比如String sql = "SELECT * FROM users WHERE id = " + userId;这种写法，它通过AST分析+污点追踪，把用户输入（如HTTP参数、Cookie）标记为“污染源”，再顺着数据流看是否未经净化就流入了数据库执行函数（如Statement.execute()、jdbcTemplate.query()）。但它的能力边界也很清楚：二次注入、动态表名/列名拼接、ORM中错误使用${}等场景，容易漏报；而对合法但危险的逻辑（如管理员后台绕过校验）可能误报。
扫描前必须确认的3个配置点
不是扔进代码就能扫出SQLi——配置不对，结果基本没用：
- 确保SAST工具启用了“污点分析”或“数据流分析”模式（SonarQube叫
java:S2077规则，CodeQL需加载sql-injection.ql查询） - 明确标注可信入口：比如Spring Controller的
@RequestParam、@PathVariable变量默认视为污染源；若用自定义封装类接收参数，得在工具配置里声明该类字段为source - 排除已知安全调用：像
PreparedStatement、NamedParameterJdbcTemplate、MyBatis的#{}语法，需确认工具规则库版本支持最新框架语义（旧版SonarJava可能误报Hibernate HQL参数化查询）
常见误报/漏报场景及应对方式
扫出来一堆java:S2077告警，点开却发现是误报；或者线上真出了SQLi，扫描报告却一片空白——这很常见：
-
漏报典型场景：MyBatis里写了
select * from ${tableName}，SAST若没启用“动态SQL上下文分析”，大概率跳过；修复方式是改用#{tableName}并加白名单校验，或在SAST配置中显式启用MyBatis插件 -
误报高频位置：日志打印语句含SQL片段（如
log.info("executing: " + sql)），SAST误判为执行点；可在代码里加// NOSONAR注释，或配置规则忽略日志相关方法调用链 -
框架适配坑：Spring Data JPA的
@Query(nativeQuery = true)若含字符串拼接，部分SAST工具不识别其危险性；建议统一禁用nativeQuery，改用JPQL或Criteria API
扫描结果怎么验证才不算白忙活？
别只看SAST报告里的“高危漏洞数”。真正要做的，是人工走一遍从输入到执行的数据路径：
- 对每条告警，反向追溯：源头是不是真实用户可控输入？中间有没有
StringEscapeUtils.escapeSql()这类无效过滤（它防不住UNION注入）？最终是否落到executeUpdate()或queryForObject()这类执行点？ - 重点盯
WHERE、ORDER BY、GROUP BY子句中的动态拼接——SAST对排序字段拼接（如"ORDER BY " + sortField）检测力度弱，但这是盲注高发区 - 跑一次轻量DAST交叉验证：用OWASP ZAP对告警接口发
' OR 1=1 --，看是否真返回异常数据——SAST说有风险，ZAP证实能打穿，这才算闭环
真正卡住多数团队的，从来不是工具会不会扫，而是扫出来之后敢不敢删代码、愿不愿意改框架调用习惯。SAST报的每一条SQLi，背后都对应着一个没做参数化的Statement，或一个被滥用的${}。改掉它，比调参重要得多。
