A critical CVE lands on Friday. Your team confirms the affected service is in production, internet facing, and unauthenticated. Everyone agrees it needs to be fixed immediately. There is even a vendor patch available. Then engineering comes back with the real timeline: the library is three dependencies deep, the upgrade breaks two integrations, and the next change window is in eleven days.
This is a typical cycle for organizations. Yet, this also means eleven days of exposure. Attackers can turn vulnerabilities into exploits in hours and organizations need to be able to protect themselves while working to fully remediate – while waiting on a patch.
What you do inside that window is mitigation. Remediation and mitigation are not the same treatment and that is why many fall into the trap of too much exposure. This blog goes into the details of the two and when you need which.
Remediation Removes the Vulnerability
Remediation is the permanent fix: applying the vendor patch, upgrading the dependency, rewriting the vulnerable code, or changing the configuration that made the flaw reachable. When remediation is complete, the weakness no longer exists in the environment. Scanners stop flagging it because there is nothing left to flag.
Remediation is the goal, and it is also by nature, a slower path. Patch availability depends on the vendor and the organizational processes. Deployment depends on regression testing, dependency chains, change control, and in many cases a third party whose release schedule you do not control. For deeply embedded components, remediation realistically takes weeks. Industry mean time to remediate for critical vulnerabilities is commonly measured in days or weeks, not hours.
Mitigation Removes the Attacker's Exploitable Path
Mitigation is what protects the application while the vulnerability is still present. The flaw remains in the code. The route to reaching it, or the value of reaching it, is taken away.
In practice, in one form, mitigation looks like a WAF rule that blocks the specific exploit pattern, disabling the vulnerable feature or module, restricting network access to the affected service, tightening authentication in front of it, revoking an over-permissioned token, or adding detection so that exploitation attempts are caught in progress. None of these make the vulnerability disappear. All of them change whether it can be used against you today.
Another form is through in-app blocking. The system detects anomalous behaviors and stops the pathway from executing.
The Two, Side by Side
Why Security Programs Are Going Mitigation First
The case for leading with mitigation is not that patching is unimportant. It is that remediation is slower for structural reasons that no amount of urgency removes.
Remediation crosses an organizational boundary. Security owns the finding, engineering owns the code, and the fix competes for capacity against a roadmap that was planned before the CVE existed. It queues behind release trains, change advisory boards, and the code freezes that cover exactly the periods when exposure matters most, like peak retail season or the end of a fiscal quarter. The fix is often not even yours to ship, because the vulnerable component sits inside a vendor appliance or a third-party dependency and you are waiting on someone else's release. And a meaningful share of what is running in production cannot be upgraded at all: end-of-life frameworks, legacy applications nobody has built in years, systems where the upgrade path was abandoned two versions ago.
Mitigation is the one lever a security team can pull on its own timeline. It does not require a deploy, a freeze exception, or another team's sprint. That is why mitigation first is becoming the operating default: not as a replacement for patching, but as the way to stop being exposed on somebody else's schedule.
Log4Shell Is the Case Study Everyone Lived Through
Log4Shell is the clearest example of why the distinction matters, because for several weeks the fix itself was a moving target. Log4j 2.15.0 addressed CVE-2021-44228 incompletely. 2.16.0 followed for CVE-2021-45046. Then 2.17.0 for CVE-2021-45105, and 2.17.1 for CVE-2021-44832. A team that defined success purely as "we are on the patched version" had to declare victory four separate times.
The interim guidance moved too. Setting formatMsgNoLookups to true was widely recommended at first, and Apache later confirmed it was an insufficient mitigation on its own, because message lookups could still occur through other code paths. The interim step that held up was removing the JndiLookup class from the classpath for teams that could not patch immediately.
There are two lessons in that, and they point in opposite directions. Mitigation is what carried most organizations through a fix cycle that ran far longer than a single patch window.
What Makes a Mitigation Worth Deploying
Not every compensating control is worth the operational cost. The ones that earn their place share a few traits:
- Anchored to the actual exploit path. A rule tied to the specific parameter, header, or function the exploit abuses, not a broad pattern that happens to catch a sample payload.
- Verified, not assumed. Tested against real exploit variants and against legitimate traffic, so you know both that it blocks and that it does not break the application.
- Observable. If it fires, someone sees it. A silent mitigation gives you protection with no signal that anyone tried.
- Owned and dated. A named owner and an expected retirement date, tied to the remediation ticket rather than living on its own.
Run Mitigation and Remediation on Separate Tracks
Mitigation and remediation answer different questions and should be tracked independently. Mitigation answers: is this exploitable right now? Remediation answers: is this gone? A vulnerability is not resolved until both are true, and the mitigation should be retired once the fix is deployed.
Put another way, defenders have to run on two clocks. Remediation is the slow one, and it will keep moving at human speed for good reasons: regression testing, change control, and the blast radius of touching a production system. Mitigation has to be the fast one. Shield the exploitable path now, with proof it will not break the app, and let the patch land on its own schedule.
When Defense Becomes Autonomous, Mitigation Goes First
There is a reasonable objection to all of this, and it is worth taking seriously. Frontier models are now being pointed directly at defenders. Anthropic's Project Glasswing, built around Claude Mythos, and OpenAI's Daybreak, which puts Codex Security at the center of vulnerability detection and patch validation, both promise something close to machine-speed security engineering. If a model can find the flaw and write the fix, why would anyone need a stopgap?
However, Daybreak generates patch proposals and confirms vulnerabilities in isolated environments without touching production, and every proposal goes to a human reviewer before it is applied. Glasswing has been about discovery, under tightly controlled access. Neither of them autonomously changes code running in production, and that is not an oversight. Writing the patch was never the bottleneck. The bottleneck is the change: regression risk, blast radius, rollback, and the accountability question of who signs off when an autonomous agent modifies a revenue-generating application. None of that disappears with these models.
Which is why autonomy will arrive on the mitigation side first. A mitigation is scoped, reversible, and does not require rewriting the application, so it is the part of the response you can safely hand to a machine well before you hand over production code. The realistic near-term loop is to autonomously detect, mitigate, verify, then remediate on human time. Even in a world where defense runs at frontier-model speed, the gap between "we know about this" and "it is gone from the codebase" does not close to zero. Something still has to hold the line inside it.
The patch is still the fix. Mitigation is how you survive the time it takes to get there.
To see how Miggo closes the patch gap with a mitigation-first response here.
.webp)
.webp)
