Patching is dead, but remediation speed now defines appsec risk

At a glance

What this is: This is an analysis of why sub-day exploitation has made slow remediation a bigger risk than patch availability itself.

Why it matters: It matters to IAM and security practitioners because the same speed gap now affects code security, runtime controls, and the governance of privileged remediation workflows across platforms and pipelines.

By the numbers:

• In 2024, 23.6% of known exploited vulnerabilities were attacked on or before the day their CVE was disclosed.
• The 2024 Verizon DBIR found organisations take 55 days to remediate half of critical vulnerabilities in the KEV catalog after a patch is available.
• 2025 State of Software Security report puts the, rt puts the average time to fix a flaw at 252 days.

👉 Read Pixee's analysis of why runtime protection cannot replace faster remediation

Context

Patching is no longer the only control that matters when exploitation can start before disclosure or within hours of a CVE becoming public. That changes the governance problem for security teams: the issue is not just whether a fix exists, but whether the organisation can triage, prioritise, and remediate fast enough to stay inside the attack window. In practice, this is now a broader security operations and code governance problem, not a narrow vulnerability management exercise.

For teams running application security, the identity angle appears in the remediation path itself. Privileged access to codebases, CI/CD systems, repositories, and deployment pipelines determines whether fixes move at machine speed or stall behind review queues. The article's starting position is typical of modern AppSec programmes, where runtime shielding, scanner noise, and slow developer workflows all collide at once.

Key questions

Q: How should security teams handle manual patching for actively exploited vulnerabilities?

A: Treat manual patching as a risk exposure window and compensate accordingly. Restrict exposure, monitor for exploit indicators, and prioritise the most business-critical systems first. If patching will take time, teams should assume attackers are already operationalising proof-of-concept code and should contain the service boundary immediately.

Q: Why do organisations still fall behind even when they have strong vulnerability tooling?

A: Because tooling often improves visibility faster than decision-making and engineering throughput. Many queues are full of low-value findings, while the defects attackers can actually reach sit behind manual review, dependency analysis, and release friction. The problem is not only detection. It is the time lost separating real exposure from noise and turning that decision into a merged fix.

Q: What do teams get wrong about runtime protection for exploited vulnerabilities?

A: They often treat runtime blocking as if it resolves the issue, when it only interrupts one exploitation path. Runtime reduces immediate exposure, but it leaves code debt, dependency risk, and compliance obligations untouched. If the organisation stops at runtime, the same defect will still exist when the next control fails or the workload changes.

Q: Who is accountable when remediation stays slower than exploitation?

A: Security, engineering, and platform owners all share accountability because remediation speed depends on code ownership, review capacity, and release governance. Frameworks like NIST CSF and CIS Controls expect control over vulnerabilities, but the operational test is whether teams can actually close high-risk findings before attackers do. Accountability is about throughput, not intent.

Technical breakdown

Why the exploit window is collapsing faster than patch cycles

Exploit timing has compressed because attackers now weaponise public vulnerabilities almost immediately, while defenders still depend on release cycles, maintenance windows, and manual triage. Once exploitation begins before a patch exists, the organisation is no longer choosing between patching and not patching. It is choosing between a compensating control that buys time and a remediation process fast enough to actually remove exposure. Runtime protection can stop execution, but it does not change the fact that vulnerable code remains present and observable in the backlog.

Practical implication: security teams need a remediation model that measures speed to fix, not just speed to detect.

How exploitability triage changes the remediation queue

Exploitability analysis reduces the size of the workstream by separating reachable, meaningful weaknesses from noisy findings that will never be exercised in context. That matters because large vulnerability queues fail less from lack of alerts than from lack of decision capacity. When teams use code-aware and context-aware triage, they can focus engineering effort on defects that an attacker can actually reach, rather than spending scarce time on every scanner result. This is the difference between backlog management and risk reduction.

Practical implication: prioritise reachable flaws and transitive exposure paths before they consume engineering capacity.

Where runtime protection fits in a layered remediation model

Runtime controls are compensating controls. They intercept exploitation during execution, which is valuable for workloads that cannot be patched quickly or cannot be interrupted at all. But runtime sits downstream of the development lifecycle, so it does not remove the vulnerability from source code, dependency graphs, or compliance obligations. A mature model uses runtime to narrow exposure while code-level remediation clears the standing debt. That sequencing matters because the shield should support the fix process, not replace it.

Practical implication: use runtime controls as a bridge while you drain the remediation backlog, not as a permanent substitute for fixes.

Threat narrative

Attacker objective: The attacker aims to exploit vulnerable code faster than the organisation can remediate it, preserving access to exposed attack paths before fixes land.

1. Entry occurs when an attacker reaches a vulnerability that has already been publicly disclosed or weaponised before a patch is available.
2. Escalation happens when the exploit is applied against exposed code or a reachable dependency before defenders can complete review and remediation.
3. Impact is achieved when the organisation is forced to absorb blocked attacks, backlog growth, and residual exposure despite having a compensating runtime layer.

NHI Mgmt Group analysis

Runtime protection is a compensating control, not a remediation strategy. It can stop an exploit from executing, but it does not remove the vulnerable code, the dependency flaw, or the governance debt. That distinction matters because security programmes often count blocked attacks as risk reduced when the underlying exposure still exists. The practical conclusion is simple: runtime buys time, but only remediation closes the gap.

Exploitability triage is now the real bottleneck in vulnerability governance. The article correctly shifts attention from raw scanner volume to deciding what is actually reachable and exploitable. That is the named concept here: remediation backlog friction, the accumulation of low-signal findings that slow action on high-risk defects. Security teams should treat this as a governance failure if engineers cannot distinguish urgent fix items from noise quickly enough to stay within the exploit window.

Speed without code-level closure just moves risk from the attacker to the queue. This is where the market's fascination with autonomous response needs discipline. A faster ticket loop is not the same thing as a safer application estate if the organisation still cannot generate and merge fixes at scale. For practitioners, the relevant question is whether the programme shortens exposure or merely shortens acknowledgment.

Developer workflow, not just security tooling, determines whether MTTR can shrink. The piece implicitly shows that ownership, code review, and dependency change management are all part of vulnerability governance now. If privileged access to repositories and pipelines is slow or over-controlled, remediation will lag even when security tooling is ready. Teams should treat remediation throughput as an operating model issue, not just a scanner problem.

What this signals

Remediation velocity is becoming a governance metric, not just an engineering metric. If attackers can exploit before defenders patch, the programme has to prove it can identify, prioritise, and close exposure inside a shrinking window. That shifts board reporting toward fix-time, review capacity, and control coverage rather than raw vulnerability counts.

The next pressure point will be whether AppSec teams can combine exploitability analysis with workflow automation without creating a false sense of closure. Runtime can suppress noise, but only governed remediation workflows reduce the size of the exposure estate. For identity-heavy programmes, this also means tightening privileged access to code and pipeline systems so approved fixes do not stall in review.

For practitioners

• Rebuild prioritisation around exploitability Filter vulnerability queues by reachable code paths, public exploit signals, and dependency exposure so engineers only work the findings that matter inside the attack window.
• Measure remediation against attack timing Track time to fix alongside time to exploit, and report both at the same governance level so leaders can see whether controls are keeping pace with disclosure.
• Use runtime as a bridge, not a destination Keep compensating controls on high-risk workloads while engineering teams remove the vulnerable code or dependency, then retire the runtime dependency once the fix is merged and validated.
• Reduce review friction in code and pipeline access Streamline privileged access for remediation workflows so approved fixes can move through repositories, CI/CD, and deployment gates without avoidable delay.

Key takeaways

• The article's central warning is that runtime protection cannot be the primary answer when exploitation now happens before many teams can patch.
• The evidence points to a widening gap between attacker speed and defender throughput, with remediation measured in days or months while exploitation can begin in hours.
• Practitioners should optimise for exploitability triage, faster code-level fixes, and runtime as a temporary bridge rather than a permanent substitute.

Key terms

• Exploitability-Led Triage: Exploitability-led triage is a remediation method that prioritises weaknesses based on whether they are reachable and can be chained into real attack paths. It is more effective than raw backlog ranking because it ties effort to actual exposure, not just issue count.
• Mean Time to Remediation: Mean time to remediation is the average time it takes to fix systems that are out of compliance. It measures how fast a team can move from detection to closure. Lower values usually indicate better process discipline, clearer ownership, and fewer hidden exceptions.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.

What's in the full article

Pixee's full article covers the operational detail this post intentionally leaves for the source:

• The benchmark data behind exploitability triage and runtime response timing across real attack windows.
• Context-aware remediation details showing how generated pull requests reduce hands-on fix time.
• The practical comparison between runtime shielding, autonomous mitigation, and code-level closure.
• Why the article argues that remediation throughput, not patch availability alone, now determines control effectiveness.

👉 Pixee's full article expands on exploit windows, runtime trade-offs, and the remediation model behind faster fix cycles.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in practical terms. It helps practitioners connect identity control to remediation, lifecycle, and operational risk across modern security programmes.