Until 20 August, dismissing a code scanning alert as "Won't fix" meant one of two very different things, and the label could not tell them apart: this was never actually exploitable, or this is a real vulnerability that somebody with authority decided to accept the risk on, usually because something outside the code already controls it.
Those are opposite claims about risk, filed under the same button. GitHub split them by adding "Mitigated" as its own dismissal reason.
What Mitigated actually claims
A vulnerability marked Mitigated is not fixed and not dismissed as harmless — it is acknowledged as real, with its risk controlled by something outside the code itself: a web application firewall rule, a network policy, a compensating control elsewhere in the system.
That is a fundamentally different statement from "Won't fix", which says the finding was never a genuine problem. Filing both under one label meant a security review could not tell, from the alert list alone, which dismissed findings still needed a compensating control to keep working and which ones simply were not risks.
Why the distinction is worth having
GitHub's own framing is precise: this lets organisations distinguish mitigated vulnerabilities from alerts marked Won't fix, align dismissals with formal exception and risk-acceptance processes, and reduce the need to track these decisions outside GitHub.
That last clause is the practical win. Every security team that has ever run an exception process has watched it split into two record systems — the finding lives in the scanning tool, and the actual risk acceptance, with its approver and its expiry, lives in a spreadsheet or a ticket somewhere else. A dismissal reason that maps onto the real category of decision means the two records can finally be the same one.
The trap this creates
A dismissal reason that sounds responsible is exactly the kind of button that gets misused, because "Mitigated" reads better in a compliance report than "Won't fix" does, whether or not a mitigation genuinely exists.
The distinction is only worth anything if someone checks it. A finding marked Mitigated with no linked control, no named owner and no review date is functionally identical to one marked Won't fix — it has just been relabelled to look more defensible. If your compliance process treats the label itself as evidence, this feature makes your risk register look better without making your risk lower.
What a real Mitigated dismissal needs
Three things, none of which the button enforces for you:
- A named, specific control — which WAF rule, which network policy, which compensating mechanism, not "handled elsewhere"
- An owner who can attest the control is still in place, because controls get removed and dismissed findings do not get re-evaluated automatically
- A review date. A mitigation is a statement about today's environment, not a permanent fact about the vulnerability
What to do this week
If you have a backlog of "Won't fix" dismissals, that list now needs a pass: some of them are genuinely not risks, and some were always mitigations wearing the wrong label. Reclassifying honestly is worth the afternoon, because it is the only way this feature's reporting benefit actually applies to your existing findings rather than only new ones.