GitHub Copilot 代码扫描新增 Mitigated 关闭理由：漏洞仍在时如何记录外部控制措施

GitHub 代码扫描现在多了一个容易被误用、但很有价值的关闭理由：Mitigated。它针对的是“漏洞仍然存在，但 WAF、网络策略等外部控制措施已经把可利用风险压低”的场景。这个状态不是修复完成，也不是把告警藏起来，而是把风险接受的依据留在告警记录里。

如果代码中的漏洞尚未消失，只是由可验证的外部控制措施降低了暴露面，可以用 Mitigated 记录处置结果；没有控制证据时，仍应修复或按组织流程保留告警。

GitHub 这次到底改变了什么

GitHub Changelog 在 2026 年 8 月 20 日公布了新的代码扫描告警关闭理由 Mitigated。官方给出的典型条件是：漏洞依旧存在于代码中，但 Web 应用防火墙（WAF）或网络策略等外部控制措施能够降低它的风险。

变化不在 CodeQL 如何发现问题，而在“发现之后如何留下处置语义”。以前团队常把这类告警归到 Won't fix，后来的人很难判断它是业务接受、误报，还是已经由外围防护承担。现在，关闭理由可以更准确地表达这个中间状态。

为什么不能把 Mitigated 当成漏洞修复

假设一个接口仍然存在 SQL 注入风险，但入口前有严格的 WAF 规则。此时，代码扫描结果并没有变成“安全”，只是攻击路径增加了一层外部控制。WAF 规则被删除、误配、绕过，或者接口被新域名暴露后，原来的风险可能重新出现。

这张对照表的关键是“代码状态”一列：Mitigated 并不改变扫描器对漏洞的判断，只补充了外部风险控制的语义。

一次合格的 Mitigated 记录要写清哪些证据

关闭告警前，先把控制措施写成别人能复核的事实，而不是抽象结论。可以在团队的告警评论或风险记录中保留下面四类信息：

1. 控制位置：说明是哪个 WAF 策略、网关规则或网络边界承担了拦截。
2. 覆盖范围：写清域名、接口路径、环境和流量入口，避免把测试环境的规则误当生产保护。
3. 验证结果：保留一次规则命中、拒绝响应或策略审计记录，注明验证使用的告警编号。
4. 失效条件：写出规则被调整、入口迁移、绕过路径出现时必须重新打开告警的条件。

告警：CodeQL / injection-risk / #1842
关闭理由：Mitigated
控制措施：边缘 WAF 规则 waf-sql-17
覆盖范围：api.example.test /v1/orders/*，生产入口
复核证据：规则审计记录 2026-08-20，命中后返回 403
失效条件：路由、域名或 WAF 规则变更后重新扫描

示例中的编号、路径和日期只是记录格式示例，实际填写时必须替换成团队真实存在的值。尤其不要因为 WAF 能拦一类请求，就推断所有调用路径都被保护。

把新理由接入团队的关闭流程

落地时可以把决策分成三道检查。第一道看漏洞是否已经在代码或依赖中消失；如果已经修复，就走修复后的重新扫描。第二道看外围控制是否真的覆盖当前入口；没有覆盖证据，就不要选 Mitigated。第三道确认控制措施有负责人和复核周期，否则这个状态很快会变成没人维护的历史备注。

安全团队还应把 Mitigated 与变更审计、例外审批或风险接受记录关联起来。这样在 WAF 规则调整、服务换域名或网络边界变化时，能够反向找到依赖该控制措施的告警，而不是只在代码扫描页面里留下一个孤立状态。

常见问题

Mitigated 会让 CodeQL 结果变成已修复吗？

不会。它只记录外部控制措施降低风险，代码中的漏洞仍然需要在条件允许时修复。

只有 WAF 才能使用 Mitigated 吗？

不是。GitHub 官方说明举例提到 WAF 或网络策略，实际还要看组织是否能证明控制措施覆盖了对应攻击路径。

没有审计记录，能先关闭告警再补吗？

不建议。没有可复核证据时，关闭理由无法与真实风险状态对应，应该先补齐控制位置、范围和验证结果。

外部规则变更后要做什么？

重新检查入口覆盖范围并重新扫描；如果控制措施不再有效，应恢复告警或改走修复流程。

采用建议

Mitigated 适合补齐风险处置的语义，不适合替代修复。第一次启用时，先挑一组确实有 WAF 或网络策略保护的历史告警，补录控制证据与失效条件，再观察安全团队能否在变更审计中快速找到它们。能被复核、能随控制变更重新评估，这个关闭理由才真正有用。