SAST工具在CI中检测SQL注入可行但需满足前提：能识别污点传播路径且存在可分析执行上下文；多数工具默认不报因未启用跨函数数据流分析，仅做基础语法扫描导致漏报。
直接在 CI 流水线中集成 SAST 工具检测 SQL 注入，是可行且高效的，但必须满足两个前提：工具能识别污点传播路径，且代码中存在可分析的执行上下文（比如明确的数据库调用 + 用户输入拼接）。否则，semgrep 或 bandit 这类轻量工具只会报出“疑似拼接”，而 SonarQube 或 Checkmarx 才可能给出“高置信度 SQLi”结论。
为什么多数 SAST 工具默认不报 SQL 注入？
SQL 注入本质是“用户可控输入未净化即进入危险函数”的数据流问题。SAST 工具要确认它，得同时完成三件事：识别输入源（如 request.args.get）、追踪变量赋值链、匹配危险汇聚点（如 cursor.execute）。很多工具默认关闭跨函数/跨文件的数据流分析，或仅启用基础语法扫描——这就导致漏报。
-
bandit默认只检查硬编码字符串拼接，对query = "SELECT * FROM u WHERE id=" + user_id会告警，但对user_id = request.form['id']; query = f"WHERE id={user_id}"很可能静默 -
semgrep的p/sql-injection规则依赖显式模式匹配，无法处理运行时拼接或 ORM 链式调用 -
SonarQube的 Java 规则（如S2077）需开启“数据流分析”并配置正确的源/汇标签，否则降级为字符串字面量检查
GitLab CI 中用 Semgrep 检测 Python SQL 注入的实操要点
适合中小团队快速落地，不依赖复杂部署，但需手动补全上下文断言。
- 使用
semgrep scan --config=p/sql-injection --json -o semgrep-report.json，但必须配合自定义规则增强源识别：例如添加对flask.request.*、django.http.request.GET的 source 定义 - 在
.semgrep.yml中显式声明 sink：pattern: cursor.execute(...)或connection.execute(...)，避免匹配到日志打印等误报 - 排除已知安全模式：用
-e 'not re.search(r"^[a-zA-Z0-9_]+$", value)'类逻辑跳过白名单字段名拼接（虽不推荐，但现实存在） - 输出后用脚本过滤低置信度结果：
jq '.results[] | select(.extra.metavars."user_input".start.line != null)'，只保留能定位输入行的告警
SonarQube 扫描 Java 项目时 SQL 注入规则失效的常见原因
不是规则没开，而是工程配置或代码结构挡住了数据流分析路径。
- 未在
sonar-project.properties中启用数据流引擎：sonar.java.binaries=.必须指向编译后的.class目录，纯源码扫描会丢失类型信息 - Spring Boot 项目中，JDBC 操作常被封装在
@Service层，而用户输入来自@Controller—— 若未配置sonar.java.libraries包含 Spring 框架 JAR，工具无法理解@RequestParam是 source - MyBatis 使用 XML 映射时，
<select></select>中的${}拼接不会被标记为漏洞，因为分析器不解析 XML 内容；必须改用#{}并配合自定义规则校验参数绑定完整性 - CVSS 评分阈值设为 7.0 以上才阻断流水线，但 SQL 注入默认规则可能只打 6.8 分——需在 Quality Gate 中手动上调该规则权重
真正卡住落地的，往往不是工具选型，而是输入源和危险函数之间隔着抽象层（如统一 DAO 封装、中间件拦截器），或者团队用动态 SQL 构建器（如 jOOQ）绕过了传统检测模式。这时候与其强行调参，不如先用 git grep -n "execute\|query\|sql" 锁定高风险文件，人工标注 source/sink 后再喂给 SAST 工具做定向扫描。
