TL;DR: A capacity crisis, not an awareness gap, is revealed by analysis of 35 AppSec reports: 98% of organizations experienced breaches from vulnerable code, 81% knowingly ship vulnerable code, and teams spend more time filtering noise than fixing risk, according to Pixee. The implication is that security programs must shift from finding more issues to reducing triage, prioritizing exploitable exposure, and aligning remediation with real operational capacity.
At a glance
What this is: Pixee's analysis argues that AppSec teams are drowning in triage noise while vulnerable code, exploitability and tool sprawl keep remediation behind the threat.
Why it matters: For IAM, PAM, NHI and broader security practitioners, the lesson is that control programmes fail when prioritisation is detached from real exposure and operational capacity.
By the numbers:
- 98% of organizations experienced breaches from vulnerable code in 2024, according to Pixee.
- 81% knowingly ship vulnerable code despite awareness of the risks, according to Pixee.
- 71-88% of security alerts are false positives, according to Pixee.
- 50-80% of AppSec time is spent on triage, not fixing, according to Pixee.
Context
Application security programmes fail when the volume of findings exceeds the team's ability to validate, rank and remediate them. In this article, the primary issue is not lack of awareness but a sustained capacity mismatch that turns triage into the dominant operating mode.
For identity-heavy environments, the same pattern appears when security teams have too many alerts, too little context and no reliable way to distinguish exploitable exposure from background noise. That creates governance drift across code, cloud and credential paths, and it is now a typical condition rather than an edge case.
Key questions
Q: What breaks when AppSec programs focus on findings instead of fixes?
A: Findings-only programs create the illusion of control while exploitable issues remain unresolved. Teams spend time on triage, developers disengage from noisy alerts, and the backlog grows faster than remediation can clear it. The result is a security function that measures activity but fails to reduce exposure.
Q: Why do severity scores fail to predict real AppSec risk?
A: Because severity is only a proxy for impact, not a measurement of reachability or exploitability in your environment. A high score can be low risk if the vulnerable path is isolated, while a lower score can be urgent if it sits on an exposed, business-critical code path.
Q: How should teams govern AI-generated code when they cannot review every change?
A: Teams should shift from source-only assurance to runtime assurance. That means correlating deployments, traces, logs, and outcome metrics so behaviour can be validated after code is generated and released. The practical goal is not perfect review coverage, but a dependable record of what the system actually did in production.
Q: What should security leaders do when triage is consuming most of the AppSec budget?
A: Reduce the volume of low-value findings before adding more tools or people. Then measure remediation throughput, queue age and false-positive rates as programme health indicators. If those numbers do not improve, the organisation is scaling noise, not security.
Technical breakdown
Why AppSec triage becomes the bottleneck
AppSec triage becomes the bottleneck when tools produce more findings than engineers can validate and fix. False positives, duplicate alerts and weak exploit context push teams into sorting mode instead of remediation mode. That matters because security value is created when a finding changes risk, not when it adds to the backlog. In practice, the bottleneck is not scanner coverage but decision throughput: which issues are real, which are exploitable, and which can wait without increasing blast radius.
Practical implication: reduce finding volume before expanding scanner coverage, or remediation capacity will stay hidden behind alert noise.
Why CVSS and severity scoring mislead remediation queues
CVSS is useful as a common language, but it is a poor proxy for operational priority when real-world exploitability depends on environment, reachability and exposure path. A critical score can describe a theoretical condition that never appears in production, while a lower-scored issue may sit on an active path to compromise. The result is a queue that rewards severity labels instead of risk reality. Effective prioritisation needs exploitability context, asset criticality and business reach, not just a static score.
Practical implication: rank vulnerabilities by reachability and business exposure, not by severity alone.
How AI-generated code changes the AppSec control problem
AI-generated code scales output faster than most teams can review it, which means the security problem shifts from finding defects to governing production of defects. If almost half of generated code contains vulnerabilities, then treating AI output as ordinary developer output understates the review burden. The issue is not that AI is uniquely insecure, but that it compresses the time between code creation and risk introduction. Governance has to move closer to generation, policy and automated guardrails.
Practical implication: add policy gates and secure-by-default controls around AI-assisted development before the code reaches security review.
Threat narrative
Attacker objective: The attacker objective is to exploit unresolved application and supply-chain weaknesses before defenders can turn triage into remediation.
- Entry occurs through vulnerable code, insecure dependencies or exposed third-party assets that enter production faster than teams can validate them.
- Credential and code-path weaknesses then persist because triage queues delay remediation and attackers have more time to discover exploitable paths.
- The impact is breach exposure across applications and supply-chain paths while defenders are still resolving alerts instead of removing root causes.
NHI Mgmt Group analysis
AppSec triage overload is now a governance failure, not a tooling failure. When teams spend most of their time eliminating noise, the programme stops behaving like a risk-reduction function and starts behaving like an evidence-review queue. That is a control design problem because the organisation has not limited the volume of actionable findings to what it can actually process. The practitioner conclusion is that security capacity must be treated as a control constraint, not an implementation detail.
Prioritisation that ignores exploitability creates a false sense of coverage. Static severity scores are useful only when they are reconciled with reachability, asset value and active attack paths. Otherwise, teams end up expending effort on issues that look urgent but are not materially dangerous while real exposure remains untouched. The practitioner conclusion is to treat exploitability context as part of the control, not an optional enhancement.
AI-generated code amplifies security debt faster than traditional review models can absorb it. The problem is not merely that AI code contains vulnerabilities, but that it changes the economics of review by increasing the rate at which insecure logic enters the pipeline. That creates a structural mismatch between code production and control enforcement. The practitioner conclusion is to move governance upstream into generation-time policy and guardrails.
Supply-chain exposure has become inseparable from application security operations. The article's data on third-party assets and open-source dependencies shows that teams are often triaging code they did not write and cannot fully see. That is where application security intersects with identity and trust governance: uncontrolled provenance and opaque dependency chains behave like unmanaged access paths. The practitioner conclusion is to govern provenance, not just findings.
The named concept here is triage debt: the growing backlog created when organisations can detect more issues than they can responsibly adjudicate and fix. Once triage debt becomes normal, control metrics lose meaning because the queue is no longer aligned to actual exposure. The practitioner conclusion is to measure and cap review load before adding more scanning surface.
What this signals
Triage debt is the hidden control gap in modern AppSec. Once findings accumulate faster than teams can adjudicate them, the programme stops distinguishing material exposure from background noise. That is the point where leadership should stop asking how many issues were found and start asking how much risk was actually removed.
AI-assisted development turns code review into a governance boundary. Security teams can no longer assume that downstream scanning alone will catch insecure logic at a tolerable rate. The control has to move upstream to policy, approved patterns and automated rejection of high-risk output before merge.
Supply-chain exposure now behaves like an identity and trust problem as much as a code problem. Third-party assets, dependency chains and leaked secrets widen the path to compromise, which means provenance and access scope matter alongside traditional application findings. Teams should align AppSec, identity governance and developer workflow controls around the same exposure map.
For practitioners
- Implement exploitability-first prioritisation Re-rank findings using reachability, active exposure and business criticality so the queue reflects what can actually be exploited, not just what scores high.
- Cap alert inflow at the point of generation Reduce duplicate findings, suppress low-value scanner outputs and require clear evidence of impact before a finding enters the remediation queue.
- Shift governance left into AI-assisted development Apply policy checks, secure defaults and approval thresholds to generated code before review teams inherit the vulnerability burden.
- Track triage debt as a programme metric Measure time spent validating findings, queue growth and the share of findings that reach remediation, then use those metrics to set scanner and review limits.
Key takeaways
- AppSec teams are losing time to triage because the volume of findings exceeds the capacity to validate and fix them.
- The article's evidence shows that vulnerable code, false positives and tool sprawl are combining into a structural remediation backlog.
- The practical answer is to prioritise exploitable exposure, control finding volume and move governance closer to code generation and dependency intake.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001; TA0006; TA0010 — Initial Access; Credential Access; Exfiltration | The article ties vulnerable code and stolen credentials to attacker entry and downstream impact. |
| Recommendation — Map exposed code paths and credential misuse to these tactics and prioritise the paths that lead to real compromise. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities Identified and Documented | The article is about identifying vulnerabilities but failing to convert them into effective remediation. |
| PR.DS-05 — Data is Protected from Unauthorized Access, Modification, or Destruction | The breach and supply-chain findings point to weak protection of code and secret-bearing assets. | |
| Recommendation — Use ID.RA-01 to inventory vulnerabilities in terms of exposure and then enforce priority based on business impact. Apply PR.DS-05 to protect code, secrets and dependency artifacts that attackers can turn into access. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Continuous vulnerability management is central when fix capacity cannot keep up with findings. |
| Recommendation — Use CIS-7 to reduce backlog age and make remediation decisions against verified exposure, not raw volume. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Misconfiguration, weak controls and noisy findings all point to bad security configuration hygiene. |
| Recommendation — Apply API8 where exposed interfaces and misconfigurations are producing avoidable application risk. | ||
Key terms
- Triage debt: Triage debt is the accumulated backlog of alerts, tuning work, and unworked cases that grows when analysts spend too much time on repetitive disposition. It behaves like operational technical debt: if automation does not reduce it, the organisation may lower costs without improving real resilience.
- Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
- Alert Avalanche: Alert avalanche is the condition where improved visibility produces more security events than the team can triage effectively. In NHI environments, multiple tools may flag the same identity behaviour separately, creating duplicate work and masking true priority. The fix is correlation and case management, not more noise.
- Security Capacity Crisis: A state in which the organisation's ability to investigate and remediate findings is persistently lower than the rate at which risk is introduced. In AppSec, this shows up as growing queues, delayed fixes and teams treating constant noise as normal.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect identity governance to broader security operations and risk reduction.
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