Notifications
Clear all
Topic starter
20/08/2026 6:09 pm
TL;DR: AppSec teams are spending millions on manual triage while 78% of alerts go uninvestigated, and the real bottleneck is not detection but the three separate decisions behind every finding, according to Pixee. The structural problem is becoming harder to manage as AI-generated code, dependency sprawl, and zero-day velocity increase the volume and complexity of review.
NHIMG editorial — based on content published by Pixee: Agentic Security Engineering, $1.88M/Year on Triage Labor
By the numbers:
- A 14-person AppSec team spending 80% of its time on triage represents $1.88 million in annual labor costs.
- 66% of organisations are facing 100,000+ vulnerability backlogs.
- 34% of organisations report that more than 60% of their code is now AI-generated.
Questions worth separating out
Q: How should security teams reduce noise in application security triage?
A: They should correlate scanner results with runtime exposure, reachability, ownership, and compensating controls before assigning priority.
Q: Why do scanner tools create so much extra work for AppSec teams?
A: Each scanner uses different heuristics, severity scales, and detection assumptions, so teams often spend more time reconciling tool disagreement than fixing risk.
Q: What do security teams get wrong about vulnerability prioritisation?
A: Security teams often treat vulnerability scores as if they represent operational risk on their own.
Practitioner guidance
- Measure triage labour by decision type Track how much time reviewers spend on false positive validation, business-context exceptions, and exploitability assessment.
- Reduce scanner arbitration before adding more tools Inventory overlapping scanners, compare severity logic, and remove duplicative coverage where two tools produce the same class of noisy finding.
- Add reachability evidence to every high-volume workflow Require code-path validation for findings that recur at scale, especially in dependency-heavy applications.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- The salary and backlog arithmetic behind the $1.88 million triage estimate
- The three-decision framework applied to false positives, won't-fix decisions, and risk re-scoring
- The reachability-analysis discussion showing where automation helps and where it still falls short
- The impact of AI-generated code, dependency sprawl, and zero-day velocity on AppSec review capacity
👉 Read Pixee's analysis of the hidden labor cost of AppSec triage →
AppSec triage overload: what practitioners need to fix first?
Explore further
20/08/2026 6:45 pm
AppSec triage debt is now a governance failure, not an efficiency gap. When 78% of findings are never investigated, the organisation is no longer managing security alerts, it is rationing expert attention. That creates a control gap across validation, prioritisation, and remediation, because the programme cannot consistently separate real risk from noise. For identity programmes, the lesson is direct: trust in any control collapses when the review process itself is saturated. Practitioners should treat triage throughput as a governance metric, not a back-office inconvenience.
A question worth separating out:
Q: How can teams tell if AppSec triage is breaking down?
A: Look for long queues, repeated scanner disagreement, rising exception volume, and engineers spending most of their time classifying findings rather than resolving them. If critical alerts routinely wait for manual review, the programme is over-relying on expert labour. That is a signal to redesign the workflow, not ask reviewers to work faster.
👉 Read our full editorial: AppSec triage is consuming budget while alerts remain uninvestigated
