Patch first when a tested fix exists and the change is low risk. Mitigate first when no fix exists, when testing would take too long for an internet-facing system, or when the patch could break something critical. In most cases you do both in sequence: mitigate now, patch as soon as it is safe.
The four inputs
Four facts drive the choice.
First, is a fix available? If not, mitigation is the only move. Second, is the system exposed to untrusted networks? Exposure raises urgency. Third, is exploitation reported? NIST describes patching as preventive maintenance, and a confirmed attack turns it from routine into urgent. Fourth, how risky is the change? A kernel update on a clustered database is not the same as bumping a library in a stateless service.
Decision table
| Fix available | Exposed to internet | Exploitation reported | Suggested move |
|---|---|---|---|
| Yes | Yes | Yes | Mitigate in minutes, patch within hours |
| Yes | Yes | No | Patch on the fast track, mitigate if it will slip |
| Yes | No | Yes | Patch on the fast track |
| Yes | No | No | Patch in the next scheduled window |
| No | Yes | Yes | Mitigate or remove from exposure now, watch for the fix |
| No | Yes | No | Mitigate, watch for the fix |
| No | No | Any | Restrict access, watch for the fix |
The table is a starting point. Your own change policy and the vendor's guidance win when they conflict with it.
What counts as a mitigation
Common mitigations include disabling the vulnerable feature, blocking a path or port, restricting access to a trusted network, and virtual patching with a web application firewall rule. OWASP defines a virtual patch as a policy enforcement layer that prevents exploitation of a known vulnerability, and it also warns that such rules do not fix the flaw and can be evaded. Track them and remove them once the real fix is in.
For longer reading on the options, see four patching scenarios and emergency mitigation when no patch exists yet.
When patching is the wrong first step
Patching straight into production without a test can cause an outage that is worse than the vulnerability. If you must go fast, use a small pilot group first. If the system is fragile, a mitigation buys time to test properly. Always keep a rollback path, which is covered in a rollback plan for emergency patches.
Where Safeguard fits
Safeguard's autonomous remediation can open fix pull requests for dependency updates. It is off by default, and every category starts on Manual, so a person approves each change. Policies and gates can then block builds that still contain the vulnerable version.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for which findings already have a fixed version available.
Quick check
Is mitigating a substitute for patching?
No. A mitigation reduces the chance of exploitation while you prepare the fix. Plan to remove it once the patch is verified.
What if the patch needs a reboot we cannot afford?
Mitigate first, schedule the reboot in the earliest safe window, and record the exception with an expiry date.
Sources
Last reviewed: 19 October 2026.
