Semgrep 生产落地案例

五、生产落地案例

案例一：PR 增量门禁，先把「拦住新增」做起来。背景是一个多语言的中台仓库，历史代码积累了上万条告警，团队一开始尝试全量接入，结果是每次流水线红一片，开发同学直接选择忽略，工具形同虚设。做法是改成两步走：第一步只卡增量，用 --baseline-commit 对齐目标分支，只报告本次改动引入的新问题，历史存量不参与门禁；第二步，把命中的问题按 severity 分成两档，ERROR 阻断合并，WARNING 只评论提醒。关键配置是把规则分目录管理：rules/security/ 放会阻断的规则，rules/advice/ 放建议类规则，两套 --config 分别跑，门禁只看前者。效果是新代码引入的高危写法明显减少，且因为不追究存量，团队接受度高。踩过的坑有三个：一是全量扫描太慢，几十万行的仓库跑一遍要很久，改成增量后单次只跑几十秒；二是误报太多导致信任崩塌，团队专门花了两周做规则调优——给每条规则补上 pattern-not 排除已做处理的写法，把 severity 按实际可利用性重新定级，并约定「连续两周零真实命中的规则要么收紧要么下线」；三是规则误伤测试代码，用 paths.exclude 把测试目录与自动生成的代码排除掉。

案例二：用 nosemgrep 白名单 + 定期复核收敛告警。背景是引入了第三方 SDK 之后，某条规则在 SDK 调用处持续报错，但那些调用是官方封装、参数由内部常量传入，实际不可利用。做法是：在确认无风险的那一行上方加 // nosemgrep: ok-custom-runtime-exec-concat 注释，并强制要求在注释里写清理由与责任人（通过代码评审卡住「只写 nosemgrep 不写理由」的提交）；同时把白名单条目登记到一份清单里，每季度复核一次：SDK 升级或调用方式变化时，白名单要重新评估并尽量删掉。效果是告警数量收敛到「每条都值得看」的水平，开发不再麻木。坑与解决：一是白名单变成永久豁免，因为没人管，后来靠季度复核清单和「白名单条目必须带到期日」的约定治住；二是有人图省事在文件级别加抑制注释，把整片代码都放过了，评审时明确禁止，只允许行级抑制；三是规则升级后出现新的误报，把 --test 单测加进流水线后，规则改动必须先过单测才能合，避免了「改规则把别人代码搞红」。

漏洞分级与修复闭环：扫描出来的问题统一进缺陷池，按「可利用性 × 影响面」定级——能直接导致命令执行、注入、越权的定为阻断级，必须当次修完；需要特定前置条件才能利用的定为高优，限期修；信息泄露类、依赖版本提示类定为中低优，排期处理。每个条目要有单号、责任人、修复方案、验证方式，修复后用同一份规则复扫确认不再命中，才关闭工单。整个闭环的结果要能追溯，但报告本身属于内部敏感材料，只在团队内部流转。