The exploit window didn’t shrink. It flipped.
TL;DR: Time-to-Exploit (TTE), the gap between vulnerability disclosure and first observed exploitation, has gone negative. Mandiant’s M-Trends 2026 report shows attackers now exploit vulnerabilities, on average, before a patch is publicly available and we see the same in running environments. That breaks the foundational assumption every legacy CNAPP architecture was built on — that defenders have time. The market is responding by trying to scan faster. You cannot scan your way to negative time. The only architecture that survives is one that sees and acts during execution.
The most expensive assumption in security right now
Almost every cloud security stack in production today rests on a single, quiet assumption: that defenders will have time.
Time to scan. Time to triage. Time to open a ticket, route it to the right team, write a fix, test it, deploy it, verify it. Time for the patch cycle to do its work. Time for the weekly vulnerability review to mean something. Time for the monthly posture report to still be roughly accurate when it lands in someone’s inbox. Sound familiar?
That assumption used to be reasonable. It is now, on average, wrong by about a week. Yikes.
To put it more bluntly: Using agentless scanning once every 24 hours when an attacker moves in sub-20 minutes is irrelevant. Imagine an attacker can hop in your network every 10 to 20 minutes, and you look for them once a day.
This is the entire thesis of the post in one sentence. Most security architectures were built on a tempo that no longer exists, and the gap between how fast attackers move and how often defenders look is now the single biggest source of preventable risk in the cloud.
The numbers backing it are not subtle. CrowdStrike’s 2026 Global Threat Report measured the average eCrime breakout time, the interval between initial compromise and first lateral movement, at 29 minutes in 2025, a 65% acceleration in a single year. The fastest observed breakout was 27 seconds. In one documented intrusion, data exfiltration began within four minutes of initial access. Adam Meyers, the report’s lead author, summarized it as plainly as anyone has: “Adversaries are moving from initial access to lateral movement in minutes. Security teams must operate faster than the adversary to win.”
Most security teams are not operating in minutes, they are operating in scan cycles. Every 24 hours is considered fast. Every week is considered standard. Every month is considered acceptable for non-critical assets. None of those cadences match the threat anymore.
Then Mandiant’s M-Trends 2026 report made the architectural problem unavoidable. Google Threat Intelligence Group disclosed that the average Time-to-Exploit across vulnerabilities they tracked was negative one day in 2024, and is estimated at negative seven days in 2025.
Read that again. Negative.
On average, attackers are now exploiting vulnerabilities before patches publicly exist. The patch window did not shrink. It inverted.
Here’s the math the industry has been quietly avoiding: defenders need a median 55 days to patch half of CISA’s critical Known Exploited Vulnerabilities. Attackers, on average, need a few hours. Every scan-based security architecture was built on that grace period. The grace period is now gone.
When I first saw the negative-TTE number, it wasn’t surprise. It was confirmation. We had been watching the same pattern play out in customer environments for months. During Shai Hulud, and again during the Axios supply chain attack, we saw the same attack patterns repeat across multiple customer environments before the exploit was public — let alone before a fix existed. The data caught up to what our sensors were already telling us.
How the window collapsed
Three forces compressed it, and they are all still accelerating.
Industrialized N-day exploitation. Once a vulnerability is disclosed, proof-of-concept code lands on GitHub or in dark-web forums within hours. Combined with internet-wide scanners like Shodan and FOFA, even unsophisticated actors can mass-exploit at scale. Flashpoint’s data shows N-days now account for over 80% of all known exploited vulnerabilities tracked over the past four years.
Reverse-engineered patches. When vendors ship fixes, sophisticated threat actors diff the patch, derive the underlying flaw, and weaponize it before defenders can deploy the update. The patch is the exploit roadmap.
AI-assisted exploit generation. University of Illinois researchers demonstrated in 2024 that GPT-4 could autonomously exploit 87% of one-day vulnerabilities when given only the CVE description. All at a cost of roughly $8.80 per exploit, about 2.8× cheaper than hiring a human penetration tester for thirty minutes.
A recent case shows what this looks like when it lands on real infrastructure. On April 8, 2026, the maintainers of Marimo — an open-source Python notebook used widely in AI and ML workflows published an advisory for a critical pre-authentication RCE flaw, later assigned CVE-2026-39987.Sysdig observed the first in-the-wild exploitation 9 hours and 41 minutes later, with no public proof-of-concept code available. The attacker built a working exploit from the advisory text alone, opened a shell, and exfiltrated AWS credentials in roughly three minutes. Within days, 11 IPs across 10 countries had launched 662 follow-on exploit events, including a previously undocumented malware variant deployed through a typosquatted Hugging Face Space.
That’s the operational reality of negative TTE. By the time a CVE-based scanner has a signature to look for, the attacker has been in for hours and the credentials are already gone.
The market’s answer is to scan faster but that’s the wrong answer.
Every major CNAPP vendor has staked a position on collapsing TTE. New industry coalitions are pairing frontier AI models with human red teamers to find exploitable vulnerabilities before adversaries do. Security graphs are being expanded with exposure scoring and reachability. Posture-first platforms are bolting cloud detection and response onto existing CNAPP stacks. Even runtime-leaning vendors are doubling down on insights and AI-powered prioritization.
These are real product investments. They’re not bad ideas. They are, however, all answering the same question: How do we find exploitable things faster?
That question made sense when TTE was 745 days and even when it was 44. But It makes less sense when it’s five and it stops making sense entirely when it’s negative.
You cannot scan your way to negative time. No amount of better discovery, smarter prioritization, or faster ticketing closes a gap the attacker has already crossed. When the exploit happens before the patch exists, the entire scan-triage-ticket-remediate loop is solving a problem that no longer reflects how attacks actually unfold.
The architectural question the data is forcing isn’t how do we find faster. It’s what do we need to see and do during execution that the attacker needs us not to see?
I’ve watched this market argue with itself about runtime for years. There’s still a belief that sensors and real-time profiling of workloads are optional — a privilege you add when you have time, not a requirement you build on. In a world filled with AI-assisted software and AI-assisted exploits, that belief has become indefensible. Runtime is no longer a nice-to-have piece of the stack. It is the only place a defender can actually meet an attacker in the same moment the attack is happening.
What an inside-out architecture actually does
There’s a category of problem you can only solve from inside the workload. It’s the most important category that matters now.
Static analysis tells you what might execute based on a manifest. Posture scanning tells you what might be misconfigured at the moment you scanned. Reachability analysis tells you what an attacker might be able to touch from the outside. All useful. All snapshots. All blind once execution begins.
A runtime-first architecture sits inside the workload, watching what is actually happening: which processes are running, which syscalls they’re making, which packages are loaded, which network connections are open, which API calls are flowing through Layer 7. That telemetry doesn’t replace posture or scanning, it contextualizes them and it does something neither one can do, which is observe and intervene during the execution window itself.
Concretely, that means three things change:
Prioritization becomes truthful. When a CVE lands, the question is no longer “could this be exploited in our environment?” but “is the vulnerable function actually in use, in this workload, right now, with internet exposure and a path to sensitive data?” In real customer environments, that filter cuts the noise from thousands of theoretical CVEs to the handful that are actually executable. We’ve measured up to 98% reduction in alert volume, not because we suppress alerts, but because most alerts describe a world that doesn’t exist in production.
Detection happens during the exploit, not after. Look back at the Marimo case. The attacker opened a shell on a server, spawned a terminal process, read environment files, exfiltrated credentials. None of that required a CVE to be known. All of it was anomalous behavior on the exploited workload. Meaning, anomalous processes, anomalous file reads, and anomalous network egress, all visible in real time to any sensor watching the workload itself. Runtime sensors observe the actual exploit behavior as it unfolds, regardless of whether the underlying CVE has been disclosed yet.
Response can be enforcement, not just notification. Detection alone is insufficient when the attack is mid-execution. Runtime visibility that cannot block, contain, or sever a connection is just better forensics. The architecture has to do both.
This is the difference between a security platform that tells you what happened and one that operates in the same time domain as the attack.
Why this is an architecture problem, not a feature gap
You cannot retrofit this. As I mentioned earlier, it’s the part of this conversation the market keeps avoiding.
CNAPPs built between 2019 and 2022, what we’d call Generation 2, the agentless graph era, were designed around an assumption that has now broken: that the gap between disclosure and exploitation gave defenders enough time to discover, prioritize, and remediate before attackers showed up. That assumption shaped the data model, the ingestion cadence, the alerting logic, the entire user experience. Adding a runtime sensor to that architecture later doesn’t make it runtime-native. It makes it a posture platform with a runtime feature. More explicitly, the runtime data is in the building, but the building was never designed to run on it.
Generation 3 of cloud security, the runtime-first generation, starts from a different premise. The runtime fabric is the foundation. Posture, vulnerability management, identity, and application security all consume runtime context, not the other way around. It changes what the platform can see, how fast it can act, and what categories of attack it can stop versus merely report.
When TTE was positive, both architectures could claim to solve the same problems. When TTE goes negative, only one of them can.
The AI question the market is mostly getting wrong
There’s a reflexive answer in cloud security right now: AI is helping attackers, so we need AI to help defenders. It’s not wrong, but it’s incomplete in a way that matters.
Respected practitioners have been pushing back on the most breathless framing. Marcus Hutchins recently argued that a significant share of cybersecurity disinformation is now coming from cybersecurity vendors themselves, specifically, from the logic that “AI-powered threat actors could only be stopped by AI-powered security products, so you need to buy their AI-enabled magic box.” Kevin Beaumont coined the term “cyberslop” for the same pattern. Their point isn’t that AI is irrelevant to attackers. It’s that the operational impact of AI on most attacks remains constrained by what the rest of the attacker’s toolchain can do.
The actual asymmetry isn’t AI-vs-AI. It’s that AI is removing the friction attackers used to face — exploit development, target identification, lateral movement planning — while defenders are still operating on cycles designed around human-paced workflows. The defender’s bottleneck isn’t intelligence. It’s time-to-action.
A runtime architecture compresses time-to-action because the signal and the response live in the same place. AI inside that runtime architecture amplifies it. AI bolted onto a discovery-first architecture mostly produces faster reports about things that already happened.
What this means for security leaders right now
If you’re a security leader trying to figure out what to do with this, here’s the honest answer.
You don’t need to throw out your existing tooling. Posture management, vulnerability scanning, attack-path analysis, these still matter. They are not, however, sufficient on their own anymore, and any vendor telling you otherwise is selling you the architecture they happen to have built.
The questions to ask your current and prospective vendors are different than they were three years ago:
- What can you actually see and do during the execution window? Not in the next scan cycle, not in the next ingestion batch, but right now, while the attack is happening?
- When a CVE drops at 9 AM and is being exploited by 11 AM, what does your platform do between 9 and 11 that doesn’t depend on the CVE being known to your scanner?
- Where does your runtime telemetry live in the data model? Is it the foundation that contextualizes everything else, or is it a stream that feeds back into a posture-first graph?
- What can your platform enforce, not just detect? A sensor that watches without acting is forensics, not defense.
These are architectural questions, and they sort the market quickly.
We didn’t improve the dashboard. We rebuilt the map.
When we started Upwind in 2022, we made a bet that turned out to be the right one for the wrong reason. We believed runtime would matter because it gave defenders better signal. We were right about that, but we missed how dramatically the time pressure was about to change. Negative TTE wasn’t on the whiteboard.
What we built was a runtime fabric that unifies sensors, cloud telemetry, and Layer 7 traffic inspection as the foundation of every security capability and it turned out to be the architecture this moment requires, not because we predicted it perfectly, but because we refused to treat runtime as a feature you add to a posture platform. Instead, it was the platform.
The attacker hops in every 20 minutes. If you only look once a day, you have already lost the part of the fight that mattered.
The exploit window flipped. The architecture that survives is the one that was already standing inside it.
Curious what runtime-first looks like in your environment? See a live walk-through of the Upwind runtime fabric. Get a demo →
