Review
GitHub Code Scanning Adds “Mitigated”: When Is It Safe to Dismiss an Unfixed Vulnerability?
On August 20, 2026, GitHub added a new Code Scanning dismissal reason: `Mitigated`. It is intended for situations where vulnerable code still exists, but external controls such as a web application firewall or network policy materially reduce the risk. This is more important than a new dropdown value. Security teams have long struggled to distinguish an accepted vulnerability from one that is temporarily controlled through a compensating safeguard. This article explains when `Mitigated` is appropriate, when it is not, and how to connect it to formal exception, evidence, ownership, expiry, and remediation workflows.
# GitHub Code Scanning Adds “Mitigated”: When Is It Safe to Dismiss an Unfixed Vulnerability?
## Article Summary
On August 20, 2026, GitHub added a new Code Scanning dismissal reason: `Mitigated`. It is intended for situations where vulnerable code still exists, but external controls such as a web application firewall or network policy materially reduce the risk. This is more important than a new dropdown value. Security teams have long struggled to distinguish an accepted vulnerability from one that is temporarily controlled through a compensating safeguard. This article explains when `Mitigated` is appropriate, when it is not, and how to connect it to formal exception, evidence, ownership, expiry, and remediation workflows.
---
A security finding does not always have an immediate code fix.
Legacy systems may not be upgradeable this week. A third-party dependency may not yet have a patched version. A production change window may be closed.
Organizations often use compensating controls such as:
- WAF rules;
- network isolation;
- private access;
- feature flags;
- authentication restrictions;
- temporary policy controls.
The vulnerability remains in the code.
The attack path, however, may be materially reduced.
Previously, teams often used `Won't fix`, even though that status was semantically wrong.
`Mitigated` provides a more precise distinction.
## Mitigated is not Fixed
The model is:
```text
vulnerability remains
→ code is unchanged
→ compensating control is active
→ practical risk is reduced
→ alert is dismissed as Mitigated
```
Do not report Mitigated findings as remediated vulnerabilities.
Track them separately from:
- Fixed;
- False Positive;
- Won't fix;
- Open.
## Good use cases
### WAF protection
A vulnerable request pattern cannot be patched immediately, but a tested WAF rule blocks the exploit pattern and is monitored.
### Network policy
A vulnerable administrative endpoint is no longer internet reachable and is restricted to explicitly authorized internal identities.
### Feature disabled
The vulnerable functionality is disabled in production through a controlled feature flag.
### Strong access boundary
A weakness depends on unauthenticated access, but production requires tightly enforced identity, MFA, device trust, or source-network restrictions.
## Bad use cases
Do not use Mitigated because:
- the team believes the issue is “not very serious”;
- no one has exploited it yet;
- few users use the system;
- the team plans to fix it later;
- developers dislike the scanner;
- exploitation appears difficult without evidence.
If a result is genuinely incorrect, use False Positive.
If the organization simply accepts the risk and does not plan to fix it, that is closer to Won’t fix or a formal risk-acceptance process.
## Mitigated versus Won’t fix
A useful distinction is:
```text
Won't fix
= vulnerability exists
+ organization accepts the risk
Mitigated
= vulnerability exists
+ a specific compensating control reduces the risk
```
The second state requires evidence.
## Add four fields internally
A professional workflow should capture at least:
```text
Mitigation Type
Control Owner
Evidence
Expiry Date
```
Example:
```yaml
reason: mitigated
control: WAF_RULE_2318
owner: security-platform
evidence: prod-waf-policy-v12
expires_at: 2026-10-31
```
The expiry date is critical.
Compensating controls can disappear.
A WAF rule may change. A network policy may be edited. A feature may be enabled again.
Without review, Mitigated can become a permanent hiding place for security debt.
## Recommended workflow
```text
finding
→ validate
→ can code be fixed now?
yes → fix
no
↓
is a reliable compensating control available?
no → keep open / formal risk acceptance
yes
↓
verify control
→ record owner, evidence, expiry
→ mark Mitigated
→ review before expiry
```
## Why this matters in the AI coding era
Coding agents increase the volume and speed of software change.
That can also increase:
- generated code;
- dependency churn;
- security findings;
- automated changes across large repositories.
A poor outcome would be:
```text
AI creates more code
→ scanners produce more findings
→ developers dismiss more alerts
→ security data becomes meaningless
```
A distinct Mitigated state improves the data model, but only if organizations govern it correctly.
## Do not let Mitigated become a KPI loophole
If a team is measured only on:
> zero open critical findings
then moving every finding to Mitigated can make the dashboard green without making the system safer.
Track:
- critical mitigated findings;
- age of mitigations;
- expired mitigations;
- mitigations without evidence;
- mitigated-to-fixed conversion.
The desired lifecycle is usually:
```text
Open
→ Mitigated
→ Fixed
```
not:
```text
Open
→ Mitigated forever
```
## Conclusion
GitHub’s new `Mitigated` reason is a small but useful security-governance improvement.
It recognizes that practical risk can sometimes be reduced before vulnerable code is repaired.
The correct standard is:
```text
vulnerability still exists
+ compensating control is real
+ evidence exists
+ an owner exists
+ an expiry date exists
+ permanent remediation remains visible
```
Without those conditions, Mitigated can become technical-debt concealment.
For more practical GitHub, AI coding, application-security, and enterprise engineering guidance, visit **Zyentor Picks**: https://www.zyentorpicks.com/.