GitHub added "Mitigated" as a code scanning dismissal reason on 20 August, separate from "Won't fix". The distinction is real: one says a finding was never a risk, the other says it is a risk somebody controls through something outside the code.
A good distinction with no enforcement behind it becomes exactly as loose as the thing it replaced. This is how to make sure your team's use of it means what it claims to mean.
The three conditions, checked every time
A dismissal only qualifies as a genuine mitigation if all three hold. If any is missing, it is a "Won't fix" wearing a better label.
- A named, specific control. "Handled by the WAF" is not specific. "Blocked by rule 4471 on the edge firewall" is. If you cannot name the exact mechanism, you do not have a mitigation yet — you have an assumption
- An accountable owner. Someone who can be asked, later, "is this control still in place" and is expected to know the answer. A mitigation with no owner is a mitigation nobody will notice when it disappears
- A review date. The environment that made this safe today can change without anyone touching the vulnerable code — the WAF rule gets removed in a cleanup, the network policy gets loosened for an unrelated reason
A note template worth adopting as policy
Make the note itself force the three conditions rather than trusting people to remember them:
- Control: [specific mechanism and identifier]
- Owner: [name, not a team]
- Verified: [date this was last confirmed still in place]
- Review by: [date this must be checked again]
Clean up the existing backlog before trusting the new numbers
Every "Won't fix" dismissal filed before 20 August is a candidate for reclassification, and the honest work is going through them rather than leaving history under the old label while only new dismissals use the new one.
Expect the backlog to sort into three real categories once you look: genuine non-issues that stay Won't fix, real mitigations that should move to the new label with the note above, and — the uncomfortable third pile — dismissals that were neither, filed under Won't fix because that was the only option available at the time and nobody revisited it since. That third pile is real risk that has been sitting unaddressed with a label implying it was not a concern.
The review cadence a mitigation actually needs
A genuine non-issue does not decay — the code did not become more dangerous by sitting still. A mitigation does decay, because it depends on something outside the code that can change without anyone touching the vulnerable line.
That asymmetry means Mitigated findings need a recurring check that Won't fix findings do not: at minimum, confirm on the stated review date that the named control is still active and still owned. A mitigation with no expiring review date is a mitigation that will eventually be wrong and nobody will know when it happened.
What to say to an auditor
This is the test that tells you whether your usage is real. When someone asks about a specific Mitigated finding, the answer should be a control name, an owner and a date — not "we looked at this a while back and decided it was fine."
If your team cannot answer that way for a sample of your Mitigated findings today, the feature is not doing the job GitHub built it for. That is worth finding out now, in a self-check, rather than during an actual audit.