The Moat Was Scarcity: Part 2

Thank you!

You're subscribed!

Oops! Something went wrong while submitting the form.

‍
Part 1 established that AI is dismantling the scarcity that once made patch-speed defense viable, making vulnerability discovery cheaper and faster while shrinking the window defenders have to respond. With that time buffer disappearing, defenders must shift from trying to close every path before it is exploited to targeted mitigation that moves faster than an exploit, by taking advantage of their one remaining advantage: knowing their own environment better than any attacker.

The second moat

Finding the bug is only half the moat. The other half, turning a vulnerability into a reliable working exploit, was its own expensive and specialized craft. It is collapsing on the same curve. Zerodayclock puts it in a single number: with AI agents in the loop, time-to-exploit is being driven under an hour, not a quarter or a week. The step that once separated "vulnerability exists" from "vulnerability is being used against you," the step that bought defenders their working time, now compresses to about the length of a coffee break.

Put the two halves together. Finding got cheap and exploiting got cheap. The only two links that were ever hard fell at the same time, on the same curve, for the same reason. Call it what it is: a regime change, not a productivity bump. The economics that made patch-speed defense viable have been dismantled from both ends at once.

What can defenders do about it?

So what do you do, once you accept that the race is structured against you?

Start by conceding the obvious, because it is still true: patch what matters; tighten what you can; automate the rollouts. None of this is wrong. But it was already losing on operational grounds before AI showed up, and AI turned a losing fight into one that's already lost. Faster patching is necessary, but it's nowhere near enough on its own. An honest defense strategy says that out loud instead of flogging the horse harder.

The next move is to stop fighting the asymmetry and start working within it. The attacker needs the path to work once. With AI on the board, most organizations can assume the path will be found and the exploit will fire, sooner rather than later. So organizations need to move from slow comprehensive remediation to a fast, targeted mitigation strategy. There are three steps: prove, mitigate and automate.

1. Prove exploits faster

The first edge is your home-field advantage, and here, for once, policy has kept pace with the threat. You know your own environment better than any outside attacker. CISA built its newest directive on that advantage. BOD 26-04, issued on June 10, 2026, retired CVSS-first patching as federal policy and replaced it with SSVC risk-based triage.

Instead of prioritizing by a context-free severity score, CISA now requires you to ask four questions about each vulnerability:

Is the asset publicly exposed?
Is it known to be exploited?
Can an adversary automate the exploit?
How much control does it hand over if it works?

The reason CISA gives for the shift is the same one we're talking about in this two-part series: AI is collapsing the time between disclosure and weaponization from weeks to minutes. The government saw that speeding clock and rewrote its rules in response.

These four questions validate the exploit and shape your mitigation decisions. They reveal three things worth knowing, each one harder and more useful than the last.

What exactly is exposed, meaning the live internet-facing surface, not a stale inventory.
Which vulnerabilities are reachable and exploitable, which is not the same as present. A flawed component sitting in your SBOM is not a risk until the vulnerable code is reachable along the paths your application really runs. The distance between "present" and "exploitable" is where most of the noise in a modern backlog lives.
Where mitigation counts most, so you close the paths that matter first rather than spreading the same effort across findings that carry wildly different risks.

Once you know these three things, you're ready for effective mitigation actions that close off attack paths before attackers can use them.

2. Mitigate along the attack path

Once a path is proven exploitable, the response should be to close it now, without waiting on a code change. To work, mitigation has to be applied surgically rather than across the board, at the layer the exploit has to cross. The edge and the application itself are two examples of where to do that, with more enforcement points to come.

Mitigation at the edge

Mitigation at the edge is the basis for Miggo WAF Copilot. It takes your knowledge about the specific attack path and threat to a specific application, and uses it to deploy a targeted mitigation that blocks the attack immediately, without waiting on a vendor signature or an upstream patch.

This turns a WAF from a blunt instrument into a sharp weapon that's effective in a fight. A typical WAF runs at internet scale, across everyone's traffic at once. That scale forces two constraints. It can only justify signatures for celebrity CVEs, the widely publicized ones. It's not practical to roll out bespoke coverage for every niche flaw. Plus, every rule it ships has to hold a very low false-positive rate, or it blocks legitimate traffic and breaks its own customers. So most vulnerabilities go uncovered by design, and the rules that do ship are blunt.

It's like the difference between a generic drug and a targeted therapy. A generic drug has to be mass-produced to be safe for a whole population, so it can only treat common, well-understood conditions. Generic drugs can't be aggressive, because then they wouldn't be safe for the wider population. But a personalized, targeted therapy can fight the condition fiercely and harshly, because it's designed for a specific situation. The same is true for your WAF. In the hour before an exploit is everywhere, that personalized, targeted mitigation might be the only thing fast enough to matter.

Mitigation inside the application

The second enforcement point does not depend on prediction or try to outrun the clock: in-app blocking with a sensor. Every layer above it either predicts or infers, it reasons about what is likely to be exploited. A runtime sensor does not reason: it watches and it detects.

The sensor monitoring live execution catches the exploit the moment it fires, keyed to the behavior of exploitation itself rather than to prior knowledge of a specific vulnerability. The sensor immediately deploys a targeted mitigation to block and interrupt malicious execution before the exploit succeeds.

3. Best Practice: Make it Autonomous Mitigation

Autonomous Mitigation is what breaks the attacker's advantage. Proving and mitigation can only beat an attacker who works at machine speed if they run at machine speed too. That's impossible if every protection waits on someone to write a rule, deploy it, and test it by hand.

Autonomous Mitigation runs one continuous loop: prove which paths are exploitable in your environment, deploy a targeted mitigation at the edge or inside the application, verify that it blocks the exploit and its variants without disrupting legitimate traffic, and keep it in place until the patch lands. Because the loop runs within policy limits your team sets, the exploitability window closes in minutes instead of staying open for the weeks a patch cycle takes.

Where the fight moves

So build and defend on one assumption: the bug will be found, and the exploit will work. That is not a prediction about what might happen; it will happen, cheaply and soon. Everything sound in modern defense follows from taking that line literally. The win condition has moved onto ground you own, and that is not a retreat. It is the one place where the asymmetry finally runs in your favor.

See what closing the exploitability window looks like in your environment today.

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>

<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/Flip.min.js"></script>

<script>
  document.addEventListener("DOMContentLoaded", (event) => {
    gsap.registerPlugin(Flip);
    const state = Flip.getState("");
    const element = document.querySelector("");
    element.classList.toggle("");
    Flip.from(state, {
      duration: 0,
      ease: "none",
      absolute: true,
    });
  });
</script>