GitHub Code Scanning 新增 mitigated 告警关闭原因：安全团队如何区分已缓解风险

团队把一条 Code Scanning 告警关掉时，真正麻烦的往往不是点击哪个按钮，而是半年后没人说得清“为什么关”。GitHub 在 2026 年 8 月新增了 Mitigated 关闭原因：漏洞仍在代码里，但 WAF、网络策略等外部控制已经把风险压低。它适合记录“暂时接受并由外围控制”的事实，不等于漏洞已经修复。

Mitigated 最有价值的地方，是把“代码问题仍存在”和“当前暴露面已被控制”同时留下来；它不应替代修复，也不应被当成无条件的安全豁免。

这次变更解决了哪一个治理空档

不少团队之前处理告警关闭的时候，经常把「现在暂不安排修复」和「已经通过外围防护把风险兜住」两种完全不同的决策，全都塞进同一个关闭理由里。两种决策带来的后续风险完全不一样：前者是业务团队权衡后主动接受漏洞存在的事实，后者则完全依赖WAF规则、入口访问限制、网络隔离这类补偿控制。一旦外围规则哪天被误删，原本以为已经解决的风险就会直接重新暴露出来。

GitHub给出的这个新的mitigated语义边界卡得很清楚：漏洞本身在代码里仍然存在，但是对应的风险已经被外部控制措施大幅降低。这个定义不等于漏洞已经消失，也没有承诺对应的控制措施会永久生效。对安全团队来说最实在的价值，是告警列表本身就可以携带完整决策上下文，再也不用把风险判断随手写在聊天记录里，或者单独维护一份和扫描系统脱节的表格。

Mitigated 和 Won’t fix 怎么分开判断

做决策前可以先问自己一个很具体的问题：如果暂时不改代码，对应的风险是不是完全依赖一个可以验证、有明确归属人、支持定期巡检的外围控制？如果答案是肯定的，才符合选mitigated的前提条件。如果只是暂时排不上期、改动成本太高，或者是业务侧评估后直接决定接受风险，这种场景更适合走Won’t fix或者团队内部已经有的常规风险接受流程。

适合记录为 Mitigated 的情况

• 漏洞对应的服务入口只对内网开放，同时网络策略配置有明确记录，能证明公网请求根本无法触达。
• WAF对对应的攻击模式有稳定生效的规则，同时已经有对应的命中日志、定期误报复查机制和明确的维护负责人。
• 控制措施的作用范围和告警对应的服务完全匹配，不能是「整个组织大概统一都有防护」这种没法落地到具体场景的笼统判断。

不应只靠 Mitigated 盖住的情况

• 没有明确证据能证明控制规则覆盖了所有入口，或者控制措施只在部分环境生效，其他环境仍然没有防护。
• 对应的规则是临时手工维护的，没有固定轮值负责人也没有约定好的复查日期。
• 告警涉及的是高影响漏洞，补偿控制只是降低了漏洞被触发的概率，没有明确限制住可能出现的数据泄露、权限越界等核心风险。

把关闭动作接进团队的例外流程

建议把mitigated的关闭动作当成一次正式的小型风险决策，而不是扫描页面上随手点的清理操作。最少要记录四类核心信息：具体的控制措施内容、防护覆盖的边界、能证明控制生效的验证证据、下一次复查的时间。这些字段可以直接填在告警备注里，也可以放到内部工单或者团队现有的风险台账里，但填写入口必须统一，避免决策记录只留在个人的临时评论里，后面其他人接手完全找不到依据。

控制措施：WAF 规则 waf-218，仅覆盖 /api/import
证据：生产访问日志与规则命中报表，复查窗口 2026-09-07
边界：后台旧入口 /legacy/import 不在覆盖范围
责任人：应用安全轮值组
计划：在下一个版本移除危险参数解析

记录的时候重点不在字段名是否标准，核心要求是「随便换另一个同事，拿着你写的内容就能独立重新完成验证」。如果控制措施有唯一编号，就把编号、适用环境和明确的失效条件写全；如果拿不出这些明确信息，先不要急着选mitigated这个选项。

上线后先查什么，才能避免形成永久例外

告警关闭之后还要配套反向验证的流程。第一步先核查外围控制措施是不是还在目标环境正常启用；第二步用低风险的测试样例确认请求确实会经过配置好的防护入口；第三步回头核对Code Scanning的告警信息和服务发布记录，确认不会因为分支名、服务名重复或者复制仓库的操作，导致控制范围出现漂移漏判。

每次复查最好直接给出「继续维持缓解状态、转为安排修复、重新开放告警处理」这三种明确结论。尤其是WAF或者网络策略发生变更的时候，不用等到下一轮扫描周期启动再处理，控制措施本身出现变动的时候，就应该直接触发一次对应的例外复核。

团队采用前的最小检查清单

1. 确认告警对应的代码问题仍然真实存在，不是扫描引擎返回的过期失效结果。
2. 明确写出外部控制的名称、编号、生效环境、覆盖的入口路径和对应维护责任人。
3. 用日志、网络策略配置页面截图或者规则测试结果，证明对应的控制措施确实在正常工作。
4. 给出明确的复查日期和最终的修复方向，别把临时例外变成永久没人管的状态。
5. 控制措施变更、服务迁移或者入口范围扩展之后，要重新评估判断能不能继续沿用mitigated状态。

相关问题

选择 Mitigated 后是不是就不用修代码了？

不是。它描述的只是当前风险被外部控制降低，不是代码层面的缺陷已经被解决。只要控制措施存在变更的可能性，就应该保留对应的修复计划，或者按约定周期定期复查。

没有 WAF 时能不能使用这个原因？

可以关联其他类型的外部控制，比如网络策略或者访问边界限制，但必须能证明对应的控制措施和这个漏洞的暴露路径直接相关。没有可复核的客观证据就选mitigated，只会让整个风险记录完全失真。

旧告警需要全部重新处理吗？

可以先按告警的危害等级和历史关闭记录抽样复查，之前归类到Won’t fix里、但实际是靠外围控制兜底的条目，等团队流程允许的情况下，补齐证据之后就可以重新评估调整状态。

这次功能更新的实际收益根本不是多了一个新的下拉选项，而是把「漏洞代码还在」和「当前风险已经被控制」这两件事变成了系统内可检索、可审计的独立状态。团队把对应的防护证据、覆盖边界和复查日期都补全落地，mitigated才不会变成另一种被随手乱用的忽略告警的借口。