Notifications
Clear all
Topic starter
19/08/2026 3:34 pm
TL;DR: The exploit window has collapsed from weeks to days, with some vulnerabilities exploited before disclosure, according to Pixee. The practical answer is faster exploitability triage plus code-level remediation, because MTTR now determines whether security teams close findings inside the attack window.
NHIMG editorial — based on content published by Pixee: Patching Is Dead. Runtime Buys Time. Only Faster Remediation Wins
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.
Questions worth separating out
Q: How should security teams handle manual patching for actively exploited vulnerabilities?
A: Treat manual patching as a risk exposure window and compensate accordingly.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Pixee's analysis of why runtime protection cannot replace faster remediation →
Exploit windows are shrinking fast. Can remediation keep up?
Explore further
19/08/2026 4:15 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Patching is dead, but remediation speed now defines appsec risk
