评测
GitHub Code Scanning 新增 Mitigated：漏洞没修也能关闭？企业该怎么正确用
GitHub 在 2026 年 8 月 20 日为 Code Scanning 增加了一个新的告警关闭理由：`Mitigated`。它适用于这样一种现实情况——漏洞代码仍然存在，但组织已经通过 WAF、Network Policy、访问控制、隔离网段或其他外部补偿措施降低了实际风险。这个更新看起来只是多了一个下拉选项，实际上解决的是安全治理里一个长期存在的灰区：过去很多团队只能在 `Won’t fix`、误报和“线下表格记录风险接受”之间做尴尬选择。本文重点讲清 `Mitigated` 到底什么时候能用、什么时候绝对不能用，以及企业如何把它接入正式的安全例外、到期复审和技术债治理流程。
# GitHub Code Scanning 新增 Mitigated：漏洞没修也能关闭？企业该怎么正确用
## 文章摘要
GitHub 在 2026 年 8 月 20 日为 Code Scanning 增加了一个新的告警关闭理由：`Mitigated`。它适用于这样一种现实情况——漏洞代码仍然存在，但组织已经通过 WAF、Network Policy、访问控制、隔离网段或其他外部补偿措施降低了实际风险。这个更新看起来只是多了一个下拉选项，实际上解决的是安全治理里一个长期存在的灰区：过去很多团队只能在 `Won’t fix`、误报和“线下表格记录风险接受”之间做尴尬选择。本文重点讲清 `Mitigated` 到底什么时候能用、什么时候绝对不能用，以及企业如何把它接入正式的安全例外、到期复审和技术债治理流程。
---
安全扫描最容易让团队陷入一个误区：
> “只要告警还在，就必须马上改代码。”
现实没有这么简单。
有些问题确实应该立即修复，但也有不少场景是：
- 老系统短期不能升级；
- 第三方依赖暂时没有安全版本；
- 生产变更窗口尚未到；
- 代码缺陷存在，但攻击路径已经被网络策略切断；
- 高风险接口已经被 WAF 规则临时拦截；
- 系统已被隔离到只允许特定服务访问的内网。
这时安全团队通常会采取所谓 **Compensating Control（补偿控制）**。
问题在于：漏洞代码仍然存在，Code Scanning 依然会报。
过去很多团队只能写：
```text
Won't fix
```
但这并不准确。
“Won’t fix”更接近：
> 我们决定不修。
而“Mitigated”表达的是：
> 漏洞还在，但当前风险已经通过外部控制降低。
这两个决策在治理上完全不同。
## Mitigated 不是“漏洞已修复”
这是今天最需要强调的一点。
GitHub 新增的 `Mitigated` 不是：
```text
Fixed
```
它只是一个 **dismissal reason**。
也就是说：
```text
漏洞存在
↓
代码未修改
↓
外部补偿控制生效
↓
当前攻击路径被降低或阻断
↓
告警以 Mitigated 原因关闭
```
所以企业内部不能把：
> Mitigated 数量下降
当成：
> 漏洞已经全部修复。
更准确的质量看板应该分别统计：
```text
Fixed
Mitigated
Won't fix
False positive
Open
```
## 什么情况适合标记 Mitigated？
### 1. WAF 已经阻断利用路径
例如应用存在某类输入验证问题。
短期不能修改旧系统，但 WAF 已经：
- 阻断危险 Payload；
- 只允许合法请求格式；
- 开启告警；
- 有规则 Owner；
- 有规则版本。
这属于典型补偿控制。
但前提是：
> 你能够证明 WAF 规则真的覆盖当前漏洞，而不是“理论上应该有用”。
### 2. Network Policy 切断访问
例如一个管理接口存在漏洞，但生产环境已经：
```text
Internet
×
↓
Admin API
```
只允许：
```text
Internal Service Account
↓
Private Network
↓
Admin API
```
攻击面明显降低。
这种情况下也可能合理标记 Mitigated。
### 3. 功能被 Feature Flag 完全关闭
代码仍在仓库。
但当前生产：
```text
feature_enabled = false
```
且无法被普通用户打开。
这可以是临时缓解措施。
问题是：
> Feature Flag 以后会不会重新打开？
所以必须设置复审日期。
### 4. 外围身份控制降低利用风险
例如问题只在匿名访问下成立，而生产已经强制：
- SSO；
- MFA；
- Device Trust；
- IP Allowlist。
仍然可以把它纳入补偿控制分析。
## 什么情况不能用 Mitigated？
### “我们觉得不太严重”
不行。
这是风险主观判断，不是补偿控制。
### “暂时没有人攻击”
不行。
没有攻击证据不等于风险被缓解。
### “这个系统用户很少”
不行。
用户少不是技术控制。
### “我们以后会修”
不行。
这只是延期。
### “扫描器经常误报”
如果确实误报，应该使用 False Positive，而不是 Mitigated。
### “开发说这个漏洞利用很难”
要有明确证据、攻击前提和风险模型，不能靠一句口头判断。
## Mitigated 和 Won’t fix 到底怎么区分？
可以用一个非常简单的判断：
### Won’t fix
```text
漏洞存在
↓
组织接受风险
↓
不计划修复
```
### Mitigated
```text
漏洞存在
↓
组织部署了具体补偿控制
↓
风险被实质降低
↓
控制需要持续有效
```
所以 Mitigated 的核心不是：
> 不改代码。
而是：
> 有第二道可验证安全控制。
## 企业必须为 Mitigated 增加四个字段
如果只是点一下 GitHub 下拉框就结束，这个功能反而会被滥用。
建议内部安全流程至少记录：
```text
Mitigation Type
Control Owner
Evidence
Expiry Date
```
例如：
```yaml
reason: mitigated
control: WAF_RULE_2318
owner: security-platform
evidence: prod-waf-policy-v12
expires_at: 2026-10-31
```
为什么要 Expiry Date？
因为补偿控制不应该永久存在。
WAF 规则可能被删。
Network Policy 可能改。
Feature Flag 可能重新打开。
系统架构可能变化。
如果没有到期复审，所谓 Mitigated 很容易变成：
> 永久掩盖技术债。
## 推荐的完整流程
当 Code Scanning 发现高风险问题时：
```text
Finding
↓
确认是否真实
↓
能否立即修代码？
├─ 能 → Fix
└─ 不能
↓
是否存在可靠补偿控制？
├─ 否 → 保持 Open / Risk Acceptance
└─ 是
↓
验证控制有效
↓
记录 Owner、Evidence、Expiry
↓
标记 Mitigated
↓
到期自动复审
```
这才是企业正确使用方式。
## 为什么这个更新对 AI Coding 时代更重要？
AI Coding Agent 正在让代码变更速度大幅提高。
与此同时：
- 新代码更多；
- 依赖更新更频繁；
- Agent 自动修改范围更大；
- Security Findings 数量可能上升。
企业很容易陷入：
```text
AI 生成更多代码
↓
扫描发现更多问题
↓
安全团队告警爆炸
↓
开发者大量 dismiss
```
如果 dismiss reason 只有“Won’t fix”，安全数据会迅速失真。
`Mitigated` 至少让：
> “风险已通过外部控制降低”
成为一个独立、可治理的状态。
## 但 Mitigated 也可能成为新型“技术债垃圾桶”
这是最需要警惕的风险。
假设团队 KPI 是：
> Open Critical Findings 必须为 0。
最简单的作弊方式就是：
```text
Open
↓
Mitigated
↓
Dashboard 变绿
```
所以安全负责人必须看：
```text
Open Critical
Mitigated Critical
Mitigation Age
Expired Mitigation
Mitigation Without Evidence
```
不能只看 Open 数量。
## 推荐的安全看板
### 代码层
- Open；
- Fixed；
- False Positive；
- Mitigated；
- Won’t fix。
### 风险层
- Critical Mitigated；
- High Mitigated；
- 已过期补偿控制；
- 即将到期；
- 无 Evidence。
### 趋势层
- 新增漏洞；
- 修复速度；
- Mitigated 转 Fixed 比例；
- 平均 Mitigation 生命周期。
企业真正应该追求：
> Mitigated 最终转成 Fixed。
而不是长期堆积。
## 最终判断
GitHub 增加 `Mitigated` 是一个很小但很专业的安全治理更新。
它承认了一个现实：
> 风险管理并不总是“代码有漏洞 = 立刻改代码”。
但它绝对不是给团队提供一个更方便的“关闭告警按钮”。
正确用法是：
```text
漏洞仍存在
+
补偿控制真实有效
+
有证据
+
有负责人
+
有到期时间
+
后续仍计划修复
```
如果缺少这些条件，`Mitigated` 很容易从风险治理工具，变成技术债隐藏工具。
对于已经使用 GitHub Code Scanning、CodeQL 或 AI Code Review 的团队，我更建议从今天开始把这个状态正式接入内部安全例外流程，而不是只把它当成 GitHub UI 的一个新选项。
想继续了解 GitHub、AI Coding、安全治理和企业开发实践，可以访问 **智元选**：https://www.zyentorpicks.com/。我们会持续把最新开发工具变化转化成可以真正落地的工程方法。