Notifications
Clear all
Topic starter
21/08/2026 4:55 pm
TL;DR: Enterprise AppSec is stalled by a resolution gap, not a detection gap: teams run an average of 5.3 scanning tools, yet two-thirds report backlogs above 100,000 findings and critical flaws remain unpatched for 252 days, according to Pixee. The practical issue is remediation capacity, because prioritization and automation still fail when fixes do not merge, code leaves governance boundaries, or ownership is unclear.
NHIMG editorial — based on content published by Pixee: The AppSec Maturity Model: From Detection to Resolution
By the numbers:
- 252 days., flaws sit unpatched for an average of 252 days.
- Industry surveys often cite a 100:1 staffing ratio of developers to AppSec engineers.
Questions worth separating out
Q: How should security teams reduce AppSec backlogs without lowering detection coverage?
A: Treat remediation as the primary control objective, not a follow-up task.
Q: Why do vulnerability programs stall even when detection coverage is high?
A: Because detection coverage does not remove the work of fixing, testing, and merging changes.
Q: What do teams get wrong about automated remediation timelines?
A: They often automate reminders instead of governance.
Practitioner guidance
- Implement remediation throughput metrics Track time-to-fix, merge rate, and backlog ageing together so leaders can see where validated findings stall after prioritization.
- Add reachability to vulnerability triage Use reachability analysis to separate exploitable findings from theoretical noise, then route only validated issues into the patch queue.
- Automate the handoff from finding to fix Connect scanners, ticketing, code review, and CI so validated vulnerabilities become developer-ready changes instead of manual follow-up tasks.
What's in the full article
Pixee's full article covers the operational detail this post intentionally leaves for the source:
- The four maturity levels in full, including the transition criteria between manual triage, reachability-informed prioritization, cloud-based remediation, and self-hosted remediation.
- The specific bottlenecks Pixee says appear at each level, including false positives, merge rejection, and data governance constraints.
- The remediation workflow characteristics that matter most to implementation teams, including approval flow, developer integration, and audit evidence generation.
- The practical decision points for regulated environments that need controlled code and data handling.
👉 Read Pixee's analysis of the AppSec maturity model from detection to resolution →
AppSec remediation maturity: where do teams actually get stuck?
Explore further
21/08/2026 5:12 pm
Resolution is the maturity metric that matters, not scan volume. Enterprises often treat tool count and finding volume as evidence of security progress, but this article shows those numbers can mask a growing operational deficit. When vulnerability creation outpaces fix velocity, the real control failure is the inability to close risk through governed delivery. The practitioner conclusion is straightforward: AppSec maturity should be judged by how quickly validated issues are removed from production exposure.
A question worth separating out:
Q: Who should own remediation when AppSec findings involve shared platforms and application teams?
A: Ownership should be defined before the finding enters the queue. Security can triage and prioritize, but engineering, platform, or application teams need clear responsibility for implementation and verification. Without explicit ownership, issues drift between teams and stay open far too long. That is a governance failure, not a tooling problem.
👉 Read our full editorial: AppSec maturity still breaks at remediation, not detection
