The Model Isn't the Story. The Response Time Is.

For years, organizations answered the question "How secure are we?" with a deceptively simple metric: patch velocity.

The answer was often tied to a patch cycle measured in weeks. That was a reasonable proxy for security posture because vulnerabilities were disclosed, organizations prioritized remediation, and there was often enough time between discovery and exploitation for security teams to reduce risk through patching.

Increasingly, that assumption is breaking down.

Chris Konrad made the broader point in his WWT blog, With Mythos, Finding is Solved. Remediation is the Race. Finding is no longer the hardest part of the problem. The harder question is whether organizations can validate, prioritize, contain and remediate what gets found fast enough for discovery to matter.

This post builds on that idea from a metrics perspective. If discovery accelerates but every downstream step remains constrained, security leaders may still be measuring the wrong thing.

Why patch velocity worked

Traditional vulnerability management was built around a predictable sequence of events. Vulnerabilities were disclosed, researchers analyzed them, attackers evaluated opportunities for exploitation, and organizations worked through established remediation processes before patches were deployed.

The underlying assumption was simple: if organizations could remediate weaknesses faster than adversaries could operationalize them, risk would decrease.

Patch velocity became a useful metric because it reflected progress toward that goal. It showed whether teams were reducing known weaknesses inside an accepted window of time.

The problem is that vulnerability discovery and exploit development are no longer moving at the same pace they once did.

What changed

Recent conversations around frontier AI models have focused heavily on model capability. That is understandable, but it is not the only part of the story.

The UK AI Security Institute's evaluation of Claude Mythos Preview found that the model represented a step up over previous frontier models, including significant improvement on multi-step cyber-attack simulations. The evaluation also reported that Claude Mythos Preview became the first model to complete AISI's 32-step corporate network attack simulation end to end and achieved 73% success on expert-level capture-the-flag tasks.

That finding matters because the capability jump is real. But the deeper issue is not just that AI can find more. It is that much of what these systems surface was already present in the environment. Improved discovery did not create the exposure. It made more of it visible.

That is the real shift. AI is not only changing what can be found. It is changing how quickly organizations must decide whether newly surfaced exposure matters.

The Amdahl's Law problem in security operations

Amdahl's Law is usually discussed in computing performance. The basic idea is that improving one part of a system only improves the overall system to the extent that part affects the total workflow.

That concept maps cleanly to security operations.

If AI makes discovery dramatically faster but validation, prioritization, change approval, containment and remediation still move at human speed, the overall security outcome does not improve at the same rate. The bottleneck simply moves.

Speeding up discovery does not automatically speed up risk reduction. The slowest parts of the workflow still determine how fast security outcomes improve.

That is why this conversation cannot stop at model capability. The operational question is not only how fast the model can find exposure. It is how fast the organization can do something meaningful with what the model finds.

The new remediation gap

Finding vulnerabilities is no longer the primary challenge. The greater challenge is everything that happens after discovery: validation, prioritization, containment and remediation.

Organizations increasingly need to balance four distinct activities: discovering exposure, validating exploitability, prioritizing response and remediating risk.

Historically, vulnerability management focused heavily on the final step. Today, the bottleneck often exists much earlier in the process. Security teams may know that something has been surfaced, but still need to determine whether it applies to their environment, whether it is exploitable, how quickly it could be abused and what can be done before a full remediation path is available.

Discovery velocity, validation velocity and remediation velocity are no longer moving at the same speed.

The metric problem

Consider two organizations with similarly mature vulnerability management programs.

Both discover a critical exposure.

One organization identifies the exposure quickly, validates exploitability the same day, implements compensating controls and begins remediation. The second organization spends weeks determining whether the exposure even exists in its environment.

Eventually, both organizations deploy a patch.

Which organization reduced risk faster?

The answer has very little to do with the patch itself.

The difference is response velocity.

Patch metrics alone no longer tell the full story because they measure the completion of remediation, not the speed at which the organization understood and contained exposure.

The data Chris Konrad highlighted from Verizon's 2026 Data Breach Investigations Report puts this problem in sharper focus. In that dataset, exploitation of vulnerabilities became the most common initial access vector for breaches at 31%. Only 26% of critical vulnerabilities in the Cybersecurity Infrastructure and Security Agency Known Exploited Vulnerabilities catalog were fully remediated and the median time for full resolution increased to 43 days.

Those numbers reinforce the same point. The issue is not only whether organizations can find risk. It is whether they can reduce real exposure before the window closes.

Measuring what matters

Security leaders do not need to abandon patch metrics. They need to stop treating patch metrics as the only meaningful indicator of risk reduction.

A more useful measurement model includes:

• Time to identify exposure
• Time to validate exploitability
• Time to prioritize response
• Time to contain risk
• Time to prevent execution

These measurements can also be used to instrument each stage of the Continuous Threat Exposure Management (CTEM) lifecycle. Time to identify exposure aligns to discovery activities. Time to prioritize response aligns to prioritization. Time to validate exploitability aligns to validation. Time to contain risk and time to prevent execution align to mobilization and mitigation activities. Viewed this way, velocity metrics become a practical way to measure how efficiently an organization converts findings into reduced exposure throughout the CTEM process.

Those measurements also help expose where the organization is actually struggling. In some environments, remediation may be slow. In others, the larger problem may be asset visibility, exploit validation, decision latency or the inability to apply compensating controls quickly.

The bottleneck is moving.

Security metrics should move with it.

From vulnerability management to exploit prevention

As discovery capabilities continue to accelerate, organizations are being pushed toward a different objective.

Vulnerability management focuses on identifying and remediating weaknesses.

Exploit prevention focuses on preventing those weaknesses from becoming operational attack paths.

Those are related goals, but they are not identical.

An organization can be highly effective at finding vulnerabilities and still struggle to reduce risk if exposures are identified faster than they can be validated, prioritized and contained.

Improving security outcomes increasingly requires improving the entire response chain, not simply optimizing remediation workflows.

Where to start

Security leaders should start by identifying where delay actually occurs. That means understanding whether the organization is slowest at confirming exposure, validating exploitability, prioritizing business impact, applying compensating controls or completing remediation.

Prioritization should move beyond discovery date or severity alone. Exploitability, reachability, asset criticality and available containment options should influence what moves first.

Validation should operate closer to real time. If a critical exposure is surfaced, teams need a same-day process to confirm whether the exposure exists, whether it is reachable and whether current controls reduce the risk.

Containment decisions should not wait on committee review when exposure is active and remediation cannot happen immediately. Security teams need pre-approved options for isolation, access restriction, segmentation, monitoring and compensating controls.

Security leaders should also report time to contain alongside patch velocity. A vulnerability may remain open while compensating controls reduce immediate risk. That distinction matters when leaders are trying to understand whether risk is actually decreasing.

Finally, organizations should use AI defensively inside this process. AI can help accelerate triage, summarize exploit paths, suggest telemetry sources and assist with exposure validation. Those outputs still need human review, but the goal is not to replace judgment. The goal is to compress the time between discovery and action.

For organizations looking to understand where these bottlenecks exist today, a CTEM Maturity & Exposure Assessment can help establish a baseline. By evaluating exposure discovery, validation, prioritization and containment workflows, organizations can benchmark Mean time to respond (MTTR), assess CTEM maturity and stress-test existing triage processes against today's accelerated discovery environment. Understanding where the delay exists is the first step toward reducing it.

That is where the security program starts to move from vulnerability management toward exploit prevention.

What security leaders should be asking

Much of the current discussion around AI security focuses on model capability and how quickly these systems are improving.

Those are important questions, but they may not be the most useful questions for security leaders responsible for reducing risk.

The more useful lens is operational. Security leaders need to understand whether their organizations can identify exposure quickly, validate exploitability quickly and contain risk before remediation is complete.

This is where Konrad's point matters. Finding has accelerated. The race is now in remediation, containment and the operating model that connects discovery to action.

The model isn't the story. The response time is.

As discovery capabilities continue to improve, the organizations that succeed will not necessarily have the largest security budgets. They will be the ones that can identify exposure, validate risk and contain it before everyone else.

Speed is the variable.