Patching is dead, but remediation speed now defines appsec risk

At a glance

What this is: Pixee says the appsec problem is no longer patch availability but remediation speed, because the exploit window has shrunk below the pace of most vulnerability backlogs.

Why it matters: This matters because AppSec, IAM-adjacent platform teams, and security engineering leads now have to treat triage and fix velocity as a control objective, not just deployment hygiene.

By the numbers:

• In 2024, 55 days was the time it took organisations to remediate half of the critical vulnerabilities in CISA's Known Exploited Vulnerabilities catalog after a patch was available.

Context

Application security is no longer limited by whether a patch exists. The governance gap is that exploitability now moves faster than most teams can triage, validate, and merge a fix, which means backlog management has become a security control problem rather than a pure engineering workflow.

In practical terms, runtime protection can delay impact, but it cannot remove the vulnerable code or reduce the standing repair debt. For programmes that manage application pipelines, APIs, and code-adjacent identity controls, the real issue is whether remediation can happen inside the exploit window rather than after it has already closed.

This is a broad operational problem, not an edge case. The article's starting point is typical of modern appsec teams facing rising vulnerability volume and slower fix cycles, so the pressure on governance, ownership, and engineering throughput is now the norm.

Key questions

Q: What breaks when remediation takes longer than the exploit window?

A: When remediation lags behind exploitation, the security programme loses its ability to reduce exposure before attackers act. Runtime controls may blunt impact, but they do not remove the vulnerable code or the backlog debt. The result is a standing risk state where defenders are always late, and every new disclosure adds more pressure to an already growing queue.

Q: Why does exploitability matter more than patch status in urgent response?

A: Patch status only tells you whether the defect has been fixed. Exploitability tells you whether an attacker can actually use it right now. If a vulnerability is reachable, exposed, and unmitigated, it remains dangerous even when the patch exists but cannot yet be deployed safely.

Q: What do teams get wrong about mobile runtime protection?

A: They often place too much trust in a single visible control point. If a hook, debugger, or instrumentation tool can identify where the check lives, that control becomes easy to target. Runtime defence works better when checks are distributed, varied, and backed by server-side validation rather than treated as a single barrier.

Q: How should teams govern vulnerability backlogs when attack speed is measured in days?

A: They should manage vulnerability backlog as an operational risk queue with clear ownership, service levels, and escalation thresholds. Findings that remain open past the realistic exploit window need executive visibility, because the issue is no longer whether the team found the flaw, but whether it can still close it before it is used.

Technical breakdown

Why exploit windows now outpace patch cycles

Exploitability has shifted from a post-disclosure race to a pre-disclosure or same-day event. Once public reporting, exploit kits, and proof-of-concept code circulate quickly, defenders do not get a long planning window. The technical problem is not just vulnerability existence but the delay between detection, validation, prioritisation, code change, test, and release. That delay creates a control gap where attackers can act while the fix is still moving through normal engineering queues. In appsec terms, the risk variable is no longer just whether a flaw exists, but whether the organisation can shrink the full remediation loop below the attacker's usable window.

Practical implication: Prioritise exploitability-aware triage so the remediation queue reflects real attack exposure, not scanner volume.

What runtime protection changes and what it cannot change

Runtime protection blocks or constrains an exploit as it executes. That makes it valuable for workloads that cannot be taken down, legacy systems that cannot be quickly changed, and urgent situations where a patch is not yet ready. But it is a compensating control, not a fix. The vulnerable binary, library, or code path still exists, and the organisation still carries the liability, audit burden, and future exposure if the shield fails or the workload moves outside coverage. Runtime therefore reduces immediate impact, but it does not reduce the underlying remediation debt that accumulates in the backlog.

Practical implication: Use runtime controls as a bridge, not a substitute for fixing the vulnerable code path.

How exploitability analysis changes remediation economics

Exploitability analysis narrows the work to what is actually reachable and relevant in the organisation's code and dependency graph. That matters because a large share of scanner output never becomes a real exploit path in context, and teams waste scarce engineering cycles sorting noise from urgency. When the analysis is accurate, security can send developers fewer, higher-confidence fixes and reduce the rework that causes merge resistance. The architecture shift is from ticket-first security to change-first security: generate a validated code change, not just a finding. That is what makes remediation throughput improve without simply adding more people to the queue.

Practical implication: Build exploitability gating into vulnerability workflows before issuing fixes to engineering teams.

Threat narrative

Attacker objective: Exploit vulnerable software before defenders can complete remediation and reduce the opportunity window for successful abuse.

1. Entry begins when a vulnerability becomes publicly known or is exploited before patch availability, collapsing the defender's reaction window.
2. Escalation occurs when attackers weaponize the flaw faster than internal triage can determine whether the finding is truly reachable in the affected code path.
3. Impact follows when the organisation is still scheduling or reviewing remediation while the exploit is already usable, leaving the vulnerable asset exposed until the fix lands.

Breaches seen in the wild

• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Remediation speed has become the decisive appsec control. When exploitation happens on day zero or before disclosure, the security question is no longer whether a patch exists, but whether the organisation can turn validated findings into merged fixes before the attack window closes. That shifts programme ownership toward engineering throughput, exploitability intelligence, and backlog governance. The practical conclusion is that fix velocity is now a measurable security outcome, not just a delivery metric.

Runtime protection is a compensating control, not a governance model. It can absorb some of the blast radius while teams work, but it leaves the vulnerable code, dependency, or reachable path intact. That means the control buys time without removing the root condition that auditors, customers, and regulators eventually care about. The practitioner conclusion is to treat runtime as a temporary shield while remediation removes the exposure.

Exploitability triage is the named concept that now separates noise from risk. The article points to a real governance problem: teams cannot defend everything at once, and a queue full of unreachable findings wastes the very capacity needed to close what matters. By filtering for reachable, context-specific exposure, security can focus developer effort on the subset that changes attack outcomes. The practitioner conclusion is to move prioritisation to the front of the remediation loop.

AppSec backlog management is now a security discipline. The problem is not only vulnerability discovery but the mismatch between attacker speed and internal change control. That puts ownership, escalation paths, and remediation SLAs on the same footing as detection and response. The practitioner conclusion is to govern vulnerability queues as operational risk, not as an engineering inbox.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
• Read next: AI Coding Agents Security Guide

What this signals

Exploitability triage is becoming the real bottleneck in appsec governance. Security teams that still prioritise raw scanner output over reachable risk will spend their fastest capacity on issues that were never going to matter, while the exploitable backlog keeps growing. The practical shift is to decide faster what can actually be abused, then route only that work into engineering.

Remediation speed is now a board-relevant security metric. If the average time to mitigate a leaked secret is 36 hours, according to the 2024 State of Secrets Management Survey, organisations should expect similar pressure to collapse fix cycles wherever public exploitability shortens the window. The programme implication is that MTTR, not just detection coverage, now defines exposure.

Runtime controls should be measured as temporary loss-reduction, not outcome success. Once they become the main story, they can mask a backlog that is still compounding underneath. The better governance model is to treat them as a bridge to code-level remediation, then retire them as soon as the fix ships.

For practitioners

• Implement exploitability-first triage Rank findings by reachable attack path, exposed surface, and dependency criticality before assigning engineering work so the queue reflects true attack pressure.
• Separate runtime shielding from permanent remediation Use runtime protection only for the interval between disclosure and merged fix, and track every shielded flaw until the underlying code change lands.
• Measure remediation as a security SLA Track mean time to remediation alongside detection and response, and escalate any class of issue whose fix time routinely exceeds the observed exploit window.
• Automate code-level fix generation where safe Generate reviewed pull requests for validated, high-confidence issues so engineers spend time approving and testing fixes rather than researching every finding from scratch.
• Keep the vulnerable backlog visible Report open exploitable issues separately from blocked issues so runtime coverage does not hide the number of still-unfixed findings.

Key takeaways

• Exploit windows now shrink faster than many remediation queues can move, which makes fix velocity a core security control.
• Runtime protection helps absorb immediate risk, but it does not eliminate the vulnerable code or the backlog behind it.
• Programmes that combine exploitability triage with code-level remediation are better positioned to close exposure before attackers can use it.

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.
• 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.
• 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.
• Exploit window: The exploit window is the period between when a weakness becomes known or reachable and when it is no longer usable by attackers. In practice, this window matters more than disclosure dates, because a vulnerability can be fully public and still harmless if execution is blocked.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of operational control. It is useful for practitioners who need to connect identity governance to broader remediation and access risk.