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.
At a glance
What this is: Pixee argues that AppSec backlog growth is being driven by a remediation capacity gap, not a detection gap, with open vulnerabilities and slow fix cycles now outpacing team throughput.
Why it matters: This matters because IAM, NHI, and application security programmes all depend on a realistic remediation model, and excessive backlog turns vulnerability management into security debt that attackers can exploit.
By the numbers:
- 66% of organizations are wrestling with a backlog of over 100,000 vulnerabilities.
- Critical flaws now sit unpatched for an average of 252 days.
- The average application generates about 17 new vulnerabilities a month.
Context
AppSec backlogs grow when discovery outpaces the organisation's ability to triage, prioritise, and actually change code. In practice, that means the security programme accumulates open findings faster than engineering can absorb them, especially when development velocity is high and the codebase spans first-party code, dependencies, containers, IaC, and APIs.
This is also an identity-adjacent governance problem because security teams often identify the risk while developers hold the execution authority to remediate it. When that authority, workflow, and tooling are misaligned, vulnerabilities become durable objects in the backlog rather than short-lived findings in the development lifecycle.
Key questions
Q: What breaks when AppSec teams can find vulnerabilities faster than they can fix them?
A: The control loop breaks. Detection creates backlog, backlog creates triage debt, and triage debt turns into persistent exposure windows. Once that happens, security teams lose the ability to convert visibility into risk reduction, and the programme becomes a reporting function instead of a remediation function.
Q: Why do critical vulnerabilities remain open for so long in modern appsec programmes?
A: They stay open because remediation is harder than detection in modular environments. Teams often lack complete dependency context, fear breaking load-bearing services, and do not have documented rollback playbooks. The result is deferral, not ignorance. Mature programmes reduce this by linking each finding to owners, dependencies, and business impact before deciding what to fix first.
Q: What are the signs that an AppSec program is struggling to separate real risk from noise?
A: Common warning signs include too many findings scattered across disconnected tools, slow triage, and developers being overwhelmed by alerts that are not clearly prioritized. When security teams cannot correlate findings into a single risk picture, true issues get buried. Strong programs reduce noise, consolidate signals, and help teams focus on the vulnerabilities that matter most.
A: Security teams should define the policy and acceptance criteria, while engineering teams own implementation and verification inside the codebase. The IDE plugin can accelerate remediation, but accountability still sits with the people approving code changes and the teams governing secure development standards. Clear ownership prevents automation from obscuring risk decisions.
Technical breakdown
Why backlog growth becomes security debt
Backlog growth is a throughput problem. If each release introduces more findings than the organisation can close, the queue grows even when the scanning programme is effective. In software security, that creates security debt: unresolved weaknesses accumulate interest in the form of exposure time, operational noise, and triage overhead. The article's numbers show a classic asymmetry, where vulnerabilities arrive continuously but remediation remains bounded by human review, coordination, and release cycles. That gap is what turns AppSec from a control function into a delayed-response function.
Practical implication: Measure remediation capacity against inflow, not just scan coverage, and treat backlog burn-down as a core control objective.
Why shifting left can still leave teams stuck
Shifting security left only works when the left-shifted control actually reduces friction. If scanning is pushed into CI/CD or IDEs without an immediate path to resolution, the result is often noise, broken builds, and ignored findings. That is not a tooling problem alone, but a workflow design problem: the control detects faster than the organisation can decide, assign, and fix. In that model, the scanner becomes an alert generator rather than a remediation enabler.
Practical implication: Embed fixes where developers work, and avoid controls that increase alert volume without shortening the time to safe code change.
How AI-generated code changes the remediation model
AI-assisted development can increase output materially, but it also increases the volume of code that enters review and testing with fewer human review cycles behind it. That changes the economics of AppSec because manual triage does not scale linearly with code production. When a material share of new code is machine-generated, remediation has to move from review-heavy governance to policy-driven automation, with clear ownership and predictable fix paths. Otherwise the backlog expands even if scanning quality improves.
Practical implication: Recalibrate AppSec controls for higher code volume by automating triage and remediation on the most repetitive vulnerability classes.
Threat narrative
Attacker objective: Exploit the organisation's unremediated software weaknesses before defenders can reduce exposure.
- Entry occurs through rapidly delivered code, dependencies, and configuration changes that introduce new vulnerabilities faster than the security team can review them.
- Credential or flaw exposure persists because critical issues remain open for months, creating a long exploitation window for attackers scanning for known weaknesses.
- Impact follows when known vulnerabilities are exploited as a breach vector, converting remediation lag into real compromise risk and financial loss.
Breaches seen in the wild
- Commvault Metallic breach 2025: A nation-state actor exploited a Commvault zero-day in Azure and may have taken app secrets that open customers' Microsoft 365 tenants.
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
Backlog growth is a governance failure, not a scanning failure. The article shows that many organisations can identify vulnerabilities but cannot convert those findings into timely code change. That means the weak point is the remediation workflow, not the detection stack. Practitioners should read this as a control design problem, not a tooling acquisition problem.
The decisive control is remediation throughput. When applications generate more vulnerabilities each month than teams can fix, risk becomes a capacity equation. This is where AppSec, engineering, and platform teams need a shared operating model that measures closure velocity, not just finding volume. The practitioner conclusion is straightforward: if the queue grows faster than it burns down, the programme is failing.
Security debt is now the right named concept for this backlog pattern. The article describes a system where unresolved findings accumulate faster than teams can repay them, and the result is deferred exposure rather than risk reduction. That concept is useful because it reframes backlog as a balance-sheet issue, where delay itself becomes a measurable liability. Practitioners should manage backlog as debt service, not as a static list of open tickets.
AppSec needs execution authority closer to the fix point. The article highlights a common mismatch where security teams own the finding but not the commit path. That matters because remediation without authority becomes reminder work, not risk reduction. The practitioner lesson is to move selected fixes into developer-native workflows and give security the ability to influence closure, not just report on it.
What this signals
Security debt is now a programme-level risk metric. When the backlog grows faster than the closure rate, the issue is no longer individual findings but the organisation's ability to convert detection into reduction. That changes how security leaders should report AppSec health: the real question is how quickly unresolved exposure is being retired, not how many alerts were generated.
The practical response is to shift measurement from volume to flow. Security teams should watch the ratio between findings created, findings triaged, and findings fixed, because that exposes where the workflow is breaking down and where automation can actually change the outcome.
For practitioners
- Define remediation capacity targets Set a monthly closure target that is tied to incoming finding volume, release cadence, and criticality so backlog growth is visible as an operating metric.
- Automate triage before developers see tickets Use policy-based filtering and deduplication so only actionable, contextualised findings reach engineering queues, reducing avoidable noise.
- Move common fixes into developer workflows Push repeatable remediation patterns into IDEs, pull requests, or build pipelines so developers can resolve issues without switching tools or context.
- Prioritise the vulnerabilities with the longest exposure windows Rank critical findings by age, exploitability, and business exposure so the programme reduces the oldest and most actionable risk first.
- Measure how many findings convert to code changes Track the percentage of alerts that become merged fixes, because a high alert count with low closure conversion indicates workflow failure.
Key takeaways
- AppSec backlogs grow when organisations can discover vulnerabilities faster than they can safely remediate them.
- Long remediation times turn known vulnerabilities into durable exposure, especially when critical issues remain open for months.
- The fix is not more alerts alone, but a remediation model that shortens the path from finding to code change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006 — Credential Access | Known-vulnerability exploitation is the attack pattern the article says is rising. |
| Recommendation — Map backlog-aged vulnerabilities to TA0006 and prioritise the flaws most likely to be abused first. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | The article is about software weaknesses and control gaps in the delivery pipeline. |
| Recommendation — Apply PR.PS-01 to reduce vulnerable code and configuration states before release. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The core problem is stale, unresolved vulnerabilities accumulating faster than they are fixed. |
| Recommendation — Use CIS-7 to track vulnerability age, closure rate, and remediation backlog as operational metrics. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The article highlights code and workflow patterns that let vulnerabilities persist into production. |
| Recommendation — Use V15 to push secure design and remediation patterns into the development lifecycle. | ||
Key terms
- Security Debt: Accumulated risk that builds when vulnerabilities, unsafe dependencies, and policy gaps are left unresolved across the software lifecycle. In AI-assisted development, security debt grows quickly because more code is produced, more decisions are made automatically, and remediation often lags behind delivery.
- Remediation Throughput: Remediation throughput is the rate at which a team can fix validated security issues relative to the number being found. It is a practical measure of whether AppSec is actually reducing exposure, rather than merely increasing visibility into a growing backlog.
- Backlog Burn-Down: The measurable reduction of open security findings over time. A healthy burn-down curve shows the organisation is closing issues faster than new ones arrive, while a flat or rising curve indicates the remediation process is failing to keep pace.
- Developer-Native Remediation: A remediation approach that places security fixes inside the tools and workflows developers already use, such as pull requests, IDEs, and build pipelines. The goal is to reduce friction so the path from finding to fix is short, repeatable, and practical at scale.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security alongside the access and lifecycle controls that underpin secure programmes. It is designed for practitioners who need to connect identity governance to the wider security controls their environment depends on.
Published by the NHIMG editorial team on August 21, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org