适合ci/cd的sql注入扫描工具组合是semgrep（主检sql拼接）+ gitleaks（防凭证泄露）+ bandit/brakeman（语言特异性补充）；需配置--error使违规即失败，并排除tests/、migrations/路径以控误报。
SQL注入扫描该选哪个工具接入CI/CD
选 sqlmap 不现实，它本质是渗透测试工具，不支持轻量级、可重复、可断言的流水线集成；真正适合 CI/CD 的是静态分析（SAST）+ 轻量动态探测组合。主流落地方案是：semgrep 做代码层 SQL 拼接检测 + gitleaks 防敏感凭证泄露（间接降低注入风险） + 可选 bandit（Python）或 brakeman（Ruby）补语言特异性规则。
-
semgrep规则开源、易定制，能精准捕获cursor.execute(query + user_input)这类硬编码拼接，且支持 YAML 配置直接塞进 GitHub Actions - 避免用
sqlmap --batch --level=3扫构建产物：它会发真实请求，可能触发生产告警、写脏数据，也不符合 CI 的“无副作用”原则 - 如果项目用了 ORM（如 Django ORM、SQLAlchemy），重点不是禁用原生 SQL，而是检查是否误用了
raw()、text()或execute()且未绑定参数
怎么让扫描结果真正阻断高危提交
默认只报错不阻断等于没集成。关键在把扫描输出转成 CI 可识别的退出码和结构化报告。
- 用
semgrep --json --output=semgrep.json --error：加--error让匹配到规则时进程返回非 0 码，GitHub Actions / GitLab CI 会自动标红失败 - 别依赖 “扫描后人工看报告”，CI 中必须设阈值——例如：只要出现
python.lang.security.insecure-sql-string-concatenation这条规则就立即 fail - 注意路径过滤：用
--exclude=tests/ --exclude=migrations/避免扫测试桩或历史迁移文件，否则误报率飙升
为什么参数化查询漏检率高但还得扫
因为开发者常在“以为安全”的地方翻车：比如用 format() 拼接表名、用 f-string 构造 WHERE 条件、或 ORM 中混用 extra() + 字符串插值。这些仍是 SQL 注入，但不属于传统参数化范畴。
-
semgrep能抓到f"SELECT * FROM {table_name}"—— 表名无法参数化，必须白名单校验，而扫描能暴露这种逻辑 - ORM 的
filter(**{dynamic_key: value})看似安全，但如果dynamic_key来自请求且未校验字段名，就会变成任意字段查询，扫描需覆盖这类动态键构造模式 - 别信“用了 PreparedStatement 就万事大吉”：JDBC 的
Statement和PreparedStatement混用、或预编译后仍用+拼字符串，工具链一样能识别出危险模式
CI 中跑扫描的性能与兼容性坑
本地秒级的扫描，在 CI 容器里可能超时或内存溢出，尤其 Node.js 或 Python 多依赖项目。
- 用
semgrep --jobs=2限并发，避免 OOM；Docker 镜像里别装完整 Python 环境，用semgrep/semgrep官方镜像更轻量 - GitLab CI 默认缓存不包含扫描结果，每次重跑；加
artifacts: [semgrep.json]并配置expire_in: 1 week方便追溯 - Java 项目慎用
find-sec-bugs：它依赖完整编译，CI 中若跳过mvn compile步骤，会漏掉字节码层的 JDBC 调用链分析
真正难的不是加一条命令，是得持续维护规则集、对齐开发习惯、并在每次 ORM 升级后验证扫描是否还覆盖新写法——比如 SQLAlchemy 2.0 的 select().where() 链式调用，旧规则可能完全失效。
