CI/CD中用Semgrep查SQL注入需按语言选官方规则集、禁用宽松模式、排除测试代码、显式指定Go语言，SQLMap仅作部署后回归验证，静态扫描须配合带原因的白名单注释及安全签字，二阶注入需人工标记数据流。
CI/CD里跑Semgrep查SQL注入，关键不是装上，而是规则选对
直接用 semgrep scan --config=python.security.potential-sql-injection . 很容易漏掉真实风险。这个配置只覆盖Python中典型的字符串拼接模式，但Go、Java或PHP项目里，db.Query("SELECT * FROM user WHERE id = " + id) 这类写法不会被触发——因为规则没匹配到对应语言的API签名。
实操建议：
- 按语言选官方规则集：
semgrep scan --config=p/python --config=p/java --config=p/go，再叠加社区维护的security-audit规则包 - 禁用默认宽松模式：加
--severity ERROR，避免把低风险日志拼接也标为漏洞 - 排除测试代码：用
--exclude tests/ --exclude vendor/，否则大量mock SQL语句会制造噪声 - Go项目必须额外启用
--lang go显式指定，否则自动推断常失败
SQLMap不适合放进CI/CD流水线，但可以当回归验证钩子
sqlmap -u "http://test-env/api?id=1" 在CI里跑会卡住整个构建：它依赖运行时响应、需要目标服务在线、且默认做5级探测（--level=5），一次扫描动辄几分钟，还可能触发WAF封禁IP。
真正可行的做法是把它挪到部署后阶段：
- 仅在预发环境（非生产）启动临时服务，暴露一个最小API端点
- 用
sqlmap -u "$PREVIEW_URL/search?q=test" --risk=1 --level=2 --batch --output-dir=/tmp/sqlmap-report限制强度和交互 - 把
sqlmap-report中的log文件用脚本解析，提取含"injection not detected"的行作通过判断 - 失败时发送钉钉告警，但不中断CI，避免阻塞发布
静态扫描必须配合白名单注释，否则误报会拖垮团队节奏
工具扫出 query := "SELECT * FROM users WHERE name = '" + name + "'" 报高危，但实际这段代码在内部管理后台，输入来自RBAC权限校验后的管理员表单——它本就不该走参数化，硬改反而引入新bug。
这时候得用可审计的绕过方式：
- 在代码行上方加
# semgrep-ignore: python.sql-injection（Semgrep）或// sonar-ignore: squid:S2077（SonarQube） - 注释里必须写明原因：
// 管理后台专用接口，name字段经AuthZ校验且长度限制为20字符，无注入风险 - 所有白名单注释需在MR评审时强制要求附带安全负责人签字确认，Git hook拦截无签字提交
最易被忽略的点：二阶注入根本扫不出来，得靠数据流标记
静态工具能发现 db.Exec("INSERT INTO log VALUES ('" + input + "')")，但对“用户输入存进数据库，后续另一个定时任务读这条记录再拼SQL”完全无感——这就是二阶注入，CI里100%漏检。
目前唯一能缓解的方式是人工介入：
- 在ORM层统一打标记：比如给
SaveLog()方法加// @taint-sink: raw_sql注释 - 要求所有从数据库读取后用于SQL拼接的变量，必须显式调用
EscapeForSQL()或经过strconv.Atoi()类型强转 - CI阶段跑一个简单检查脚本：
grep -r "SELECT.*FROM.*WHERE.*\$\|query.*exec" --include="*.go" . | grep -v "Prepare\|QueryRow\|ExecContext"，抓出可疑裸查询
