安全门禁绕过行为管理

周一早上，仓库里多了个安全扫描的 CI job，第一次全量跑完，几百条告警铺天盖地，连五年前没人碰过的目录都被翻了出来。当天所有 PR 变红，作者改十几行代码，却要为上百条历史问题背锅。两周后，这个 job 被加上 continue-on-error，再过一周，有人把它从必需检查里直接拿掉。

旁观者看这件事，工具没坏，坏的是绕过的成本太低。一个门禁如果让人每天第一反应就是“怎么把它关掉”，它迟早会被关掉，而且是被悄悄地、以各种合法姿势关掉。

绕过大约有三种姿势。最温和的是软绕过，改配置让它只报告不阻断；再硬一点，直接从必需检查里去掉，或者用目录级排除、全局关闭规则把噪音一刀切掉；最隐蔽的是人情绕过，出问题就找安全负责人开个例外，开完没人记得。

为什么绕？说到底就一句：本次改动和历史债务被混在一起算账。一个人改三行代码，却要为整个仓库的旧账负责，他当然会想办法。所以最先要做的不是加严，而是把“仓库里已经存在什么”和“这次变更引入了什么”分开。前者进台账，后者才参与合并判断。

分开之后，门禁的动作也不能只有“过”和“不过”。更实际的是分三档：新增的高危、高置信、路径可达的问题阻断；置信度不足或可达性不明的先告警，限时给结论；基线里的历史问题和低风险规则仅报告、建单、不拦人。三档一划，绕过的动机就少了一大半，因为大多数 PR 不再无谓地变红。

真正要管的是绕过本身，而不是假装它不会发生。临时回退可以有，但得是仓库级开关，只授权给少数人，改动自动记进审计日志，并约定恢复时限。回退期间扫描结果照常上传、照常建单，别让问题趁这段时间消失。事后补一次复盘，弄清是规则、配置还是流程出了岔子，再把修正写回策略。

例外也一样。能修规则就别排除目录，能精确抑制到某一行就别放大范围，实在要留的例外必须写清判断人、理由、补偿措施和到期日，到期自动重新打开。如果某条规则的例外数量一路涨，那说明规则该调整了，而不是继续往里塞例外。

还有个信号值得盯：绕过门禁的次数。它比阻断次数更能说明门禁设计得对不对。绕得越频繁，越该回头看看是不是门槛一开始就架错了位置。门禁的价值不在一次拦下多少条告警，而在于让每一次新增的风险都有地方停下来，而不是被绕过去。