Patching Is Dead. Runtime Buys Time. Only Faster Remediation Wins.

Sergej Epp, the CISO at Sysdig, put it plainly on LinkedIn: patching as we know it is dead. Two-thirds of exploited vulnerabilities, he argued, get weaponized on day zero or before a patch even exists.

He is right about the diagnosis. The debate worth having is about the cure.

The loudest answer in the market is runtime protection. Detect and block the exploit as it happens, and the patch timeline stops mattering. It is a real answer, and it works for what it does.

But it treats the symptom. The vulnerability is still in your code and still counting up in your backlog. Against a sub-day exploit window, the only durable fix is to make remediation itself faster. That means compressing your mean time to remediation, not just holding attackers at the door while the queue grows behind you.

The patch window really has collapsed

Start with what is actually measurable, because the numbers here get inflated fast.

Mandiant's M-Trends tracks time-to-exploit, the gap between a vulnerability going public and the first observed exploit. In 2018 that gap was about 63 days. By 2024 the average had fallen to roughly five days. In the most recent M-Trends the mean went negative, meaning exploitation now routinely happens before a patch is even available.

VulnCheck's exploitation data says the same thing from a different angle. In 2024, 23.6% of known exploited vulnerabilities were exploited on or before the day their CVE was disclosed. In the first quarter of 2025, more than a quarter were exploited within 24 hours.

Now put that next to how fast defenders actually move. The 2024 Verizon DBIR found it takes organizations 55 days to remediate half of the critical vulnerabilities in CISA's Known Exploited Vulnerabilities catalog after a patch is available. Attackers need days while defenders need months. That is the gap everyone is trying to close, and it is why "patching is dead" resonates.

A quick note on a figure making the rounds. Kunal Anand, F5's Chief Product Officer, framed the collapse as 771 days in 2018 down to four hours in 2024. The direction is right, but those specific numbers are not sourced to any published dataset I can find, and the measured figures above tell the story without exaggeration. The window closed, and you do not need to round it to four hours to feel the pressure.

The runtime case deserves a fair hearing

If exploitation can happen in minutes, patching cannot win a foot race. That is the honest core of the runtime argument, and it is a good one.

Sysdig built its 5/5/5 benchmark on exactly this logic: five seconds to detect a cloud attack, five minutes to correlate it, five minutes to respond. Their threat research found that once an attacker finds an exploitable target, they need under ten minutes to act. Against a ten-minute attack, only a control that operates in seconds has any chance. A patch that takes weeks to schedule is not in the conversation.

Runtime protection does things nothing else can. It can virtually patch a workload you are not allowed to take down, and shield legacy systems and third-party software you cannot modify. It buys time when a critical CVE drops on a Friday and the real fix will not merge until Tuesday. For active exploitation at machine speed, a runtime control is the right tool at the right layer.

So this is not a case against runtime. Runtime belongs in a serious program. The problem is what happens when it becomes the whole strategy.

Buying time is not the same as reducing risk

Runtime protection is a compensating control. It blocks the exploit. It does not remove the vulnerability. The vulnerable code still ships, the finding stays open, and the backlog keeps climbing behind the shield.

Look at where that backlog sits today. Veracode's 2025 State of Software Security report puts the average time to fix a flaw at 252 days, up from 171 five years ago. Remediation is getting slower while exploitation gets faster, and runtime shielding does nothing to bend that curve. Every day a fix waits is another day of runtime rules to maintain and another item an auditor will eventually ask about.

There are coverage gaps too. Runtime sees what executes and gets triggered. It does not see the reachable path that has not been exercised yet, the build-time weakness, or the transitive dependency three layers down that no request has hit so far. And "we blocked it at runtime" is not an answer to a compliance obligation that says fix it.

The uncomfortable part is that a shield can hide the growing pile. Alerts get blocked and dashboards go calm while the backlog keeps compounding, until the shield has a gap or the workload moves somewhere the runtime agent is not watching. Buying time only pays off if you use the time to actually close the finding. Most teams do not, because closing findings at scale is the hard part they never had a way to do.

The durable answer is to compress MTTR itself

If the window is now days and the fix still takes the better part of a year, the strategy that survives is the one that collapses the second number. That is an MTTR reduction strategy, and it has two halves that have to work together.

First, triage by exploitability. Most of what a scanner reports is not reachable or exploitable in your specific context, and deciding what actually matters is where teams drown. Pixee's exploitability analysis cuts false positives by up to 95% and reduces triage time by around 74%, so the queue that reaches an engineer is the queue that deserves one. You stop spending your fastest days on findings that were never going to be exploited.

Second, remediate at the same speed. Triage without a fix just produces a cleaner list of things you still have not done. Pixee generates context-aware pull requests that match your code conventions, including transitive dependency upgrades, with a 76% merge rate and 91% less hands-on developer time per fix. The output is not another ticket but a reviewed change ready to merge.

Together, that is how a months-long average moves toward days. Not by shielding the vulnerability indefinitely, but by fixing it inside the window that runtime was buying. Triage and remediation are co-equal here, and the order matters. Triage is what makes automated remediation safe to trust, because you are only auto-fixing what exploitability analysis confirmed was worth fixing.

This also reaches where runtime cannot. Exploitability analysis works from the code and its reachable paths, not only from what has executed under live traffic, so it catches the transitive dependency and the untriggered path a runtime agent never sees. The unit of work stops being a ticket someone has to read, research, and route. It becomes a pull request someone only has to review, which is the difference between managing a backlog forever and actually draining it.

Why "autonomous remediation" needs triage first

There is a competing frame worth addressing directly. Vendors like Qualys are pushing autonomous remediation, and Qualys VP Debashish Jyotiprakash described the gap well: defenders move at ticket speed while attackers move at machine speed. That diagnosis is correct.

The mechanism is where it splits. Qualys TruRisk Eliminate works at the asset and infrastructure layer, combining patch deployment with patchless mitigations and asset isolation. That is genuinely useful, and the mitigate-and-isolate parts buy time much like runtime does. What it does not do is decide which of the 100,000 findings in your backlog are reachable in your code, or open the code-level fix that closes them.

Exploitability triage goes first for a reason. It decides what is real, so remediation acts on what matters, so autonomous fixes are safe to merge rather than a new source of breakage. Speed without that filter is just a faster way to churn.

Where runtime actually fits

Runtime protection is a bridge. It holds the line during the hours and days between disclosure and a merged fix, and it protects the workloads you genuinely cannot patch. Keep it. The strongest programs run both layers, with runtime covering the edge cases while fast triage and remediation clear the standing backlog behind it.

Just do not confuse the bridge with the destination. The destination is a remediation loop fast enough that the bridge only has to hold for a short crossing, not forever. When triage kills the noise and remediation ships the fix in days instead of months, runtime goes back to being what it should be: a safety net for the edge cases, not the load-bearing wall for your entire vulnerability program.

The exploit window closed. Patching on a monthly cycle lost. But the answer was never to stop fixing and start shielding. It was to fix fast enough that attack-speed and fix-speed finally meet.

For the incident-by-incident view of how fast exploitation now moves across the developer-tool supply chain, see our companion analysis on the collapsing exploit window. For why the old scanner model buckled under AI-speed code, see shift-left didn't fail, scanner noise did.