Notifications
Clear all
Topic starter
21/08/2026 4:56 pm
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.
NHIMG editorial — based on content published by Pixee: Top 10 things we learned from reading 35 AppSec reports
By the numbers:
- 98% of organizations experienced breaches from vulnerable code in 2024.
- 81% knowingly ship vulnerable code despite awareness of the risks.
- 50-80% of AppSec time is spent on triage, not fixing vulnerabilities.
Questions 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.
Q: Why do vulnerable code findings become a governance problem so quickly?
A: Because code defects often intersect with identity, secrets, and access paths.
Q: How do you know if AppSec prioritisation is actually working?
A: Look for fewer high-exposure findings lingering across sprints, faster closure of issues tied to critical assets, and less duplicate triage across tools.
Practitioner guidance
- Prioritise exploitable exposure paths Rank findings by whether they connect to reachable assets, active credentials, or privileged paths.
- Collapse duplicate security findings into one workflow Feed scanners, code review, and runtime signals into a single triage queue with deduplication rules.
- Gate AI-generated code before merge Add policy checks for vulnerable patterns, exposed secrets, and unapproved dependencies before pull requests are approved.
What's in the full report
Pixee's full analysis covers the operational detail this post intentionally leaves for the source:
- The source article lists the 35 reports reviewed and the exact evidence trail behind each headline finding.
- It breaks down the report-by-report data behind triage time, AI code risk, and supply chain exposure.
- It includes the methodology and source mapping used to synthesise the cross-report conclusions.
👉 Read Pixee's analysis of 35 AppSec reports on triage, fixes, and exposure backlog →
AppSec triage overload: what security teams need to change now?
Explore further
21/08/2026 5:13 pm
AppSec triage overload is now a governance failure, not a tooling problem. When teams spend 50 to 80 percent of their time sorting noise, the programme is no longer optimising risk reduction. It is optimising survival under volume. The lesson for identity security is direct: NHI, secrets, and code findings must be governed by exposure path and business criticality, not by alert sequence. Practitioners should treat triage capacity as a control boundary.
A question worth separating out:
Q: How should organisations respond when vulnerable code also contains secrets?
A: Treat it as both an application defect and an identity exposure event. Revoke or rotate the exposed credentials, search for reuse across pipelines and services, and investigate whether the secret enabled access beyond the original codebase. The remediation path should follow the credential, not only the repository.
👉 Read our full editorial: AppSec triage is drowning teams while real fixes lag behind
