Notifications
Clear all
Topic starter
21/08/2026 4:50 pm
TL;DR: AppSec teams are drowning in a find-but-never-fix cycle, with 66% of organisations carrying more than 100,000 vulnerabilities and critical flaws averaging 252 days to remediate, according to Pixee and cited industry research. The core problem is not detection coverage but workflow capacity, and that makes automated remediation and developer-native controls the real constraint.
NHIMG editorial — based on content published by Pixee: The Find but Never Fix Crisis: The Math Breaking AppSec Teams
By the numbers:
- 252 days, flaws now sit unpatched for an average of 252 days, and that mean time to remediation has increased 47% in just five years.
- The industry average is 100 developers for every one application security engineer.
- An average application generates about 17 new vulnerabilities a month while AppSec teams only manage to fix about six.
Questions worth separating out
Q: What breaks when AppSec teams can find vulnerabilities faster than they can fix them?
A: The control loop breaks.
Q: Why do vulnerability backlogs keep growing even when teams work harder?
A: Backlogs grow because modern applications generate far more findings than humans can triage well, especially when multiple tools report the same issue.
Q: How do you know if AppSec remediation is actually working?
A: Look for shrinking time-to-fix, fewer deferred exceptions and fewer vulnerabilities surviving multiple release cycles.
Practitioner guidance
- Measure fix latency, not just finding volume Track mean time to remediation by severity, queue age, and owner team so leaders can see when the programme is accumulating action debt rather than reducing risk.
- Move triage closer to the developer workflow Embed risk context, ownership, and suggested fixes directly in the IDE or pull request flow so remediation starts where the code change happens, not in a separate portal.
- Automate repetitive remediation paths Use safe automation for common fixes such as dependency updates, secret rotation, and configuration corrections so engineers reserve manual effort for the hardest cases.
What's in the full article
Pixee's full whitepaper covers the operational detail this post intentionally leaves for the source:
- A remediation engine blueprint for reducing backlog without adding review burden
- Implementation guidance for moving from finding-centric workflows to fix-centric workflows
- Practical approaches for measuring return on investment from automated security remediation
- Examples of self-healing software patterns for application security teams
👉 Read Pixee's analysis of the find-but-never-fix crisis in AppSec →
AppSec backlog growth: what teams need to change now?
Explore further
21/08/2026 5:08 pm
Remediation capacity is now the control plane, not scanning depth. The article shows that detection has already outgrown human response, which means governance must move from inventorying flaws to collapsing the time between finding and fixing them. In AppSec, the decisive question is no longer how many issues were found, but how many were closed before they aged into attack surface. Practitioners should treat remediation throughput as a core security metric.
A question worth separating out:
Q: How should security teams reduce security debt without slowing delivery?
A: Use a remediation model that classifies risk, routes fixes into developer workflows, and validates closure before merge. The aim is not to make every vulnerability equally urgent. It is to focus engineering time on the flaws most likely to be exploited and to make remediation part of normal delivery, not an external interruption.
👉 Read our full editorial: AppSec backlog growth is outpacing remediation capacity
