Faster than the adversary: closing the exposure window from code to runtime

The window has collapsed

For years, the defender's playbook was a reasonable bet: find the flaw, wait for a patch or fix, schedule the update or remediation. AI has broken that bet. A model can now read a security patch, infer the flaw it fixes, and produce a working exploit in minutes. The underlying weakness is older than the current AI: two decades ago, security researcher Halvar Flake built BinDiff, a tool that compares a program before and after a fix to reveal the exact vulnerability that was remediated. Every fix, in effect, doubles as a map for attacking everyone who has not yet applied it. AI just reads that map in minutes, at scale.

The same acceleration is reshaping the discovery side, where AI-driven vulnerability discovery is surfacing flaws in widely used software faster than maintainers can respond. Put the two trends together and the gap is stark. An exploit now tends to appear within hours of a flaw becoming known, while fully deploying a patch across a real environment still takes weeks. For all but the first few hours of that weeks-long wait, a working exploit is already circulating while the organization still has no fix in place. Exploitation and remediation now operate on different orders of magnitude, hours against weeks.

Time-to-exploit has collapsed to near zero, so any strategy built on winning a patch race has already lost it.

The collapse of median and mean time-to-exploit, 2018 to 2026. Data source: Zero Day Clock (as of June 19, 2026).

Two windows, one race

Picture two time windows. The first is the exploitation window: the time an adversary needs to turn a vulnerability into a working attack. The second is the exposure window: the time you need to go from detecting a flaw in your own environment to actually closing it. You do not control the first; you largely control the second. Whether you get breached often comes down to a straight comparison between the two.

For known vulnerabilities—flaws that have been publicly disclosed and usually carry a CVE identifier and an available fix—the contest looks winnable on paper. Apply the fix and the window closes. The catch is that the remediation race has a floor you cannot get under. Testing, staging, and deploying a fix across a real environment takes days at best, and the 2026 Verizon Data Breach Investigations Report found the median time to fully fix actually rose to 43 days last year, with organizations applying only about a quarter of the fixes on the U.S. catalog of known exploited vulnerabilities. That same report named vulnerability exploitation the most common way attackers break in, ahead of stolen credentials for the first time, and Mandiant's incident responders reached the same verdict, with exploitation the leading initial access vector for the sixth year in a row.

Cutting those 43 days down to one week would be a real achievement, and it would still lose, because the exploitation window is only hours wide. For a zero-day vulnerability, the situation is worse still. A zero-day is a flaw that is not yet public or has no available fix, so defenders have had zero days to prepare. There is simply nothing to apply. This is the trap hidden inside "just patch faster": it is a worthwhile lever for known bugs, but it is bounded by a floor measured in days, and it does nothing for the growing share of attacks that arrive before any solution exists. Competing on remediation speed alone means trying to outpace a window you do not control.

The way forward is not to abandon remediation but to broaden what counts as closing the window. You shrink it before code ships, by preventing flaws early, and again in production, by blocking exploits at runtime, rather than relying only on a faster fix once the flaw is already public. Remediating faster is worth doing, but this alone can never be the whole defense.

Why "detect and patch is dead" is only half right

A growing class of runtime security vendors has built its pitch on a blunt claim: the detect-and-patch model is dead. Given everything the two windows show, they are not wrong to say it. If exploitation arrives in hours while your fixes take weeks to roll out, then leaning on a once-a-month patch cycle as your primary defense is, as the data shows, closer to security theater than real protection: a routine that looks responsible but no longer stops attacks. The honest conclusion is that you need a way to stop an exploit in production, at the moment it runs, without waiting for a solution to be available. That capability is real, and it matters.

The danger lies in the next step some take: treating runtime blocking as a replacement for everything upstream of it. That is the wrong lesson, for two reasons.

First, a runtime control is a last line of defense, not the only one. Any detection layer has false negatives: the flaws or attacks it should have caught but didn't. If production blocking is the only thing standing between an adversary and your data, then a single miss is a breach with nothing behind it; you have bet the whole defense on a single wall.

Second, abandoning prevention leaves that single wall to hold back a rising tide. AI is generating more code, and more code means more vulnerabilities reaching production, even if the rate per line stays flat. Stop trying to reduce how many flaws ship, and you ask one runtime layer to hold back an ever-rising flood, forever. Finding and fixing issues earlier is what keeps the water from rising in the first place.

There is also a quieter trap. "Detect and patch is dead" can curdle into "so why bother fixing things," when, in reality, many organizations already know about far more vulnerabilities than they remediate. As we argued in a recent look at who is responsible for securing AI-built software, the constraint is usually discipline and ownership, not detection. Runtime defense should back up that discipline, not hand teams an excuse to drop it. The slogan is half right: patch cadence is no longer a defense, but prevention is not obsolete. The move is to add a runtime line of defense, not tear down the ones already in front of it.

What "stopping it at runtime" actually means

The capability those vendors are selling has a name now. Analysts call it Application Detection and Response (ADR), and it is the newest member of a family you may already know. Endpoint detection and response (EDR) watches the machine. Network detection and response (NDR) watches the traffic. Cloud detection and response (CDR) watches the cloud account. ADR watches the application itself while it runs.

That last distinction is the whole point, so it is worth being precise about how ADR differs from the tools it sits alongside. A web application firewall (WAF) guards the front door, inspecting traffic at the perimeter for malicious patterns, but it has no view of what happens inside the application and is routinely bypassed. EDR and CDR see the machine or the cloud around the application, which usually means they notice the aftermath of an exploit (e.g., a suspicious process starting) rather than the exploit itself. The closest older relative is Runtime Application Self-Protection (RASP), which did try to watch from inside the application, but it required developers to instrument their own code, an invasive step that proved hard to adopt at scale, which is why few RASP products remain.

ADR's move is to get that inside-the-application view, down to which functions are executing, without the invasive instrumentation. Many implementations observe behavior from the operating-system level, so they can tell what the application is doing in real time without touching the source code, and decide whether a given action is legitimate or the start of an attack.

A concrete case makes this tangible. Log4Shell was the 2021 flaw in Log4j, a logging library used in countless Java applications, that allowed attackers to run arbitrary code simply by logging a malicious string. The mechanism abused a feature called JNDI that normally performs harmless directory lookups over the network. A runtime defense does not attempt to recognize the malicious string, which can be endlessly obfuscated. Instead, it watches behavior: the moment the JNDI component stops performing legitimate lookups and starts fetching and executing remote code, that specific action is blocked while the rest of the logging library continues working. No patch is required because the defense targets the exploit's behavior rather than a known signature, which is also why this approach can stop a true zero-day that it has never seen before.

In terms of the two windows, this is the production-side end of your exposure window: the last line of defense for whatever prevention did not stop before code shipped.

AI rewires both sides of the line

We opened with a collapse, and AI is its engine. The same models that help defenders are—in malicious people's hands—discovering and weaponizing flaws at a pace no human team can match, whether in the form of AI pentesting agents or frontier systems like Anthropic's Claude Mythos. That is the offensive side of the race, and it is why the exploitation window keeps shrinking. But AI does something subtler too. It not only speeds up attacks against your software but also becomes a new piece of software you have to defend.

Organizations are now deploying AI agents that read data, call tools, run code, and take actions on their own. This adds a fresh attack surface that did not exist a few years ago, and it has two layers. The models themselves can be manipulated—the domain of adversarial machine learning—where crafted inputs make a model misbehave. And the agentic systems built on top of them introduce an operational layer: under the hood, each tool an agent calls is a function call, and the connective tissue that exposes those tools is increasingly the Model Context Protocol (MCP), an open standard for wiring models to external systems.

The signature threat at the agent layer is indirect prompt injection, where an attacker plants malicious instructions in content the agent will read, a web page, a document, or a support ticket, and the agent follows them as if they came from its operator. When that agent can execute code or call sensitive tools, a successful injection does not just produce a bad sentence. It can trigger real actions, up to and including the execution of attacker-chosen code. The wiring adds its own risk, since MCP servers and their configurations become components that can be abused like any other.

Here is why this belongs in the same conversation as runtime defense. Once an agent acts, its behavior is ultimately code running on a system, which means a runtime defense asks the very question raised by the Log4Shell example: Is this function doing what it is supposed to, or has something hijacked it to execute an exploit? A prompt injection that ends in malicious code execution can be caught the same way that a rogue JNDI call was. And just as clearly, this new surface has to be examined before it ships, not only watched after it does, which places AI squarely inside the shift-left-plus-runtime model we are building toward.

AI widens the race on offense and adds a new target to defend, but because an agent's actions resolve to running code, the runtime question never changes: is this behavior legitimate, or the start of an attack?

The answer is the whole lifecycle, not one stage

Put the pieces together, and the strategy stops being a choice between shifting left and defending at runtime. It is both, aimed at the same target: a shorter exposure window. They divide the work. On the left, you find and fix vulnerabilities before they ship, so for those the window never opens at all. In production, you detect, block, and respond to exploits that slip through, closing the window on flaws missed in prevention, including those with no patch to apply. Neither alone is enough: prevention keeps windows from ever opening, and runtime closes the ones that do.

This is also where finding stops being the hard part. As we have argued before, AI is making vulnerability discovery abundant and cheap, which means the differentiator is no longer how many issues you can detect but how fast you can act on them: prioritizing what truly carries risk, remediating it, and verifying that the fix actually reduced risk exposure. That closed loop, not raw detection volume, is what moves your exposure window.

It is the model Fluid Attacks has built toward for years: we already combine automated tools, AI, and human pentesters to find and help remediate vulnerabilities across the software lifecycle, with a single platform to prioritize and track them to closure. Extending that same philosophy into runtime, so that prevention and production defense share a single continuous picture of risk, is the natural next step and the direction AppSec as a whole is heading.

Know your terrain

Sun Tzu's most quoted line is also his most practical: know the enemy and know yourself, and you need not fear a hundred battles. We have spent this post on the first half, the adversary and the speed of the attack. The second half, knowing yourself, is where most programs quietly lose. You cannot shorten the exposure window for an application you forgot you were running, a dependency you did not know you shipped, or a service no one owns. They stay exposed whether or not you are watching them.

Sun Tzu was just as insistent about ground: A commander who does not know the terrain, its passes and marshes and high points, cannot move an army across it with any confidence. In software, your terrain is the full, current inventory of what you actually run: applications, APIs, components, and the open-source and third-party code inside them. Without that map, prevention has nothing to aim at and runtime defense has blind spots by default. With it, you can see where the risk concentrates and move first, which is the entire advantage speed is supposed to buy.

This is why a trustworthy inventory is not a nice-to-have at the edge of a security program. It is the ground the whole race is run on. You cannot defend, prioritize, or outrun an adversary on terrain you have not mapped, which makes knowing what you run the precondition for every other move.

Win the window, not the patch

There is no finish line in this race. The exploitation window will keep shrinking as AI gets cheaper and faster, and no single control, however good, will ever close it for you permanently. That is not a reason for despair. It is a reason to change the scoreboard. Remediating faster will still win you individual races, but it cannot be the foundation: an exploit can exist within hours of a flaw becoming known, sometimes before it, and a zero-day leaves nothing to apply in time. So stop measuring success by how fast you patch or remediate, and start measuring how rarely an attacker finds anything exploitable in production at all. That, not remediation speed, is what decides whether you get breached.

Staying ahead means refusing the false choice. Prevent what you can on the left, so fewer flaws ever reach production. Defend at runtime, so the exploit that slips through, or the zero-day with no patch, is stopped as it runs. And map your terrain first, so every other move has something to aim at. This is the cross-cutting, code-to-runtime model Fluid Attacks is built around and continues to extend, because being faster than the adversary is not a slogan; it is the whole job.

That race now runs straight through your AI systems too. As agents and large language model applications take on real work, securing them becomes part of the same effort: protecting your AI and the LLM and generative AI applications you are putting into production. Talk to us about shortening your exposure window, from code to runtime.