Mitigation

What it means

Mitigation reduces the harm a vulnerability can cause while the flaw itself stays in the code. You block a pattern at the edge, switch a feature off, tighten a permission, or add a rule to a web application firewall.

NIST calls it a temporary reduction in the impact of a vulnerability, or in the likelihood of anyone exploiting it. That word temporary carries the whole idea. Remediation removes the flaw. Mitigation buys you time to do that properly.

Why it matters

Often it is the right call. The release carrying the fix is two weeks out, the vulnerable library has no patch yet, or the code change looks risky and the exposure is small. Acting today beats a perfect fix in a fortnight.

The danger is that mitigation works. Alerts stop, the symptom disappears, and the ticket slides down the list. Two years later somebody removes a rule nobody can explain. Or a new route reaches the same code without passing the filter. The flaw is live again, and nobody is watching for it.

How it shows up

Ask one question. Where did the change happen? Anywhere other than the code holding the flaw, and you have a mitigation, however healthy the dashboard looks. A rule at the edge, a disabled feature and a tightened permission all leave the same flaw sitting where it was.

So record it as one. Write down what the mitigation covers, what it misses, who owns it and when the real fix lands. Keep the finding open until the code changes. A mitigation filed as closed comes back in the next penetration test report, usually while a customer is reading it.