SAST基线匹配失效排查

PR 里只改了十几行，扫描结果却突然冒出上百条告警，点开一看全是半年前就存在的旧问题。遇到这种情况，先别怀疑扫描器失灵，更常见的解释是基线匹配断了。基线匹配失效只有一个典型信号：原本已被认定为“已存在”的告警，被门禁重新判定成“本次新增”。

从比较基准开始逐层排查

排查顺序应该从“拿什么做比较”往上走。第一层是合并基点。diff 扫描比较的是目标分支的合并基点，不是当前 HEAD；CI 若使用浅克隆，拿不到完整历史，扫描器只能退化为全量比较，历史问题便全部算作新增。GitHub Actions 中需要设置 fetch-depth: 0，就是为这一类情况准备的。

第二层是基线产物的同步状态。静态基线文件要随目标分支一起更新：修复已进主干而基线仍留旧记录，会出现“问题修了、告警还在”；基线提前更新，旧问题又会被误判为新增。采用工具内置 diff 模式时，则要确认每个 PR 都能取到正确的目标分支引用。

第三层是代码位置变化。文件重命名、目录迁移、大规模格式化都会改变告警的定位信息，使匹配失效，表现同样是旧问题“重新出现”。这属于基线更新流程该处理的事，不是关掉门禁的理由。

第四层是规则集与扫描器版本。规则升级后多出来的命中，来源可能是规则本身而非代码变化。此时先做一次对比扫描，确认差异归属，再决定是否调整门槛。

失效之后的处置边界

确认是匹配失效而非真实新增后，处置要克制。误报走精确抑制或例外台账，写清规则、位置、判断人、理由和到期日；不要用目录级排除，也不要把 job 从必需检查里摘掉，或长期保留 continue-on-error。临时回退只针对当前 PR，用完即恢复，期间仍要上传结果、留存记录，恢复后补一次复盘，把原因写回策略文件。

基线匹配本质上是比较基准的一致性管理。基点、产物、位置、规则版本任意一环漂移，门禁就会把旧债务重新算作新风险，最终结果不是拦得多，而是没人再信它。