Notifications
Clear all
Topic starter
21/08/2026 4:44 pm
TL;DR: Most application security teams are drowning in manual triage, with 78% of alerts going uninvestigated and false positives, acceptable risk, and over-scored findings consuming the bulk of effort, according to Pixee. The real shift is from finding more issues to using context, reachability, and exploitability to decide which findings actually deserve developer time.
NHIMG editorial — based on content published by Pixee: From 2,000 Alerts to 50 Fixes: The Triage Automation Playbook
By the numbers:
- False positives typically account for 40-50% of findings in mature organizations.
- Industry research shows 88% of "Critical" CVEs aren't actually exploitable in real-world context.
Questions worth separating out
Q: What do AppSec teams get wrong about triage at scale?
A: They often treat triage as an operational nuisance rather than a governance signal.
Q: Why do false positives create so much operational drag?
A: False positives consume expert attention without reducing risk.
Q: How do you know if triage automation is working?
A: You should see fewer findings sent to developers, a higher percentage of those findings proving real, and a shorter time from validated issue to fix.
Practitioner guidance
- Build a unified finding layer Aggregate SAST, DAST, SCA, container, and cloud findings into one normalized queue so severity and duplicate issues can be compared consistently.
- Automate reachability checks Use code-path, data-flow, and callability analysis to remove false positives before developers see them, especially for dependency and injection findings.
- Enrich findings with service context Attach metadata for internal-only services, public endpoints, MFA, VPN access, segmentation, and lifecycle status so triage reflects operating reality.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- Five-step triage automation playbook with implementation sequencing for unified visibility and enrichment.
- Examples of false-positive handling across SAST, SCA, and DAST pipelines for teams tuning their workflows.
- Context fields to encode in a service registry before you automate prioritisation decisions.
- Practical guidance on when remediation automation is safe to layer in after triage.
👉 Read Pixee's analysis of the AppSec triage automation playbook →
AppSec triage automation: are your controls keeping up?
Explore further
21/08/2026 5:04 pm
AppSec triage has become a governance failure, not just an engineering burden. When 40-50% of findings are false positives and a large share of the rest are context-dependent, the issue is no longer raw detection. The real control gap is decision quality at scale, which makes triage a first-class security function. Organisations that still treat triage as ad hoc manual review are effectively outsourcing priority setting to scanner defaults, and that is not a defensible operating model.
A question worth separating out:
Q: What should teams do when a critical finding is not actually exploitable?
A: They should re-score it using environment context, document the compensating controls, and keep it in a tracked risk queue rather than treating it as an emergency. The goal is not to ignore the issue but to place it in the right priority band so it does not displace findings with real exploitation paths.
👉 Read our full editorial: Triage automation is now the AppSec bottleneck, not detection
