Security teams running continuous scanners often describe the same experience: the tool runs on every commit, the dashboard stays full, and the backlog number trends upward regardless of effort. The scanner is doing its job. The team is doing theirs. The backlog grows anyway.
The explanation is usually process, not tooling. Understanding where the hours actually go is the starting point for fixing the problem.
What a Scanner Delivers and What It Does Not
A scanner produces a list of findings. Each finding typically includes a severity rating, the file and line number of the issue, a description of the vulnerability class, and, in many tools, a reference to the related CWE or CVE. That output is useful, but it stops short of telling a developer what to change. The gap between "SQL injection at line 84 of user_service.py" and "here is the safe version of that query" is where most of the time gets spent.
This is not a criticism of scanners. Identifying the problem is a distinct task from solving it. But many AppSec programs are staffed and timed as if a finding equals a fix, and that assumption is where backlogs originate.
The Triage Burden
Before any finding reaches a developer, someone has to triage it. Triage involves confirming the finding is real (not a false positive), assessing whether the code path is actually reachable in production, determining the effective severity in context, and deciding which team owns the fix. In a codebase with active development, a single scan run can produce dozens of findings across multiple services and owners.
Triage rates vary, but in most teams we have spoken with, a significant portion of scanner output gets parked without action, not because teams are ignoring it but because they lack enough context to act confidently. Low-severity findings with ambiguous ownership tend to accumulate. Over time they form the structural base of the backlog.
The Fix Gap
Even for findings that clear triage, the developer who receives the ticket usually has to do independent research: What is the correct fix pattern for this vulnerability class in this language and framework? Does the existing code already have a utility function that handles this correctly? Will the fix break downstream behavior?
For experienced AppSec engineers, this research might take twenty minutes. For the developer who owns the service but is not a security specialist, it might take half a day of reading, asking Slack, and testing. Multiply that by the volume of findings a mid-size team generates weekly and the math explains the backlog.
Scan-plus-fix workflows are designed to close this gap. Instead of delivering a finding, the tool delivers a finding and a proposed code change, scoped to the specific function and framework. The developer still reviews. But they are reviewing a concrete proposal rather than starting from a vulnerability description.
False Positives Compound the Problem
Scanner accuracy varies by vulnerability class and language. SAST tools that track data flow through complex call graphs produce fewer false positives than tools that use pattern matching alone. But even low false-positive-rate tools produce noise at volume, and every false positive costs time: a developer opens the ticket, reads the finding, determines it does not apply, and closes it. Done once, this is minor. Done forty times a week, it erodes trust in the scanner output and creates pressure to reduce scanning frequency or scope.
We are not arguing that false positives are an unsolvable problem. The point is that false positive rate directly multiplies triage overhead. A 10% false positive rate on 200 weekly findings means 20 false tickets that each require investigation. Reducing that rate has a larger impact on team throughput than adding a second analyst.
Deduplication and Long-Tail Findings
Backlogs also grow because many findings recur. A vulnerable dependency introduced in one sprint may generate a finding on every subsequent scan until it is upgraded. Without deduplication logic that groups recurrences under a single work item, the ticket count inflates in ways that do not reflect actual distinct security problems. Teams reviewing a dashboard with 600 open findings may be looking at 120 distinct issues, each scanned four or five times.
Effective deduplication requires normalization across scan runs: matching on the finding signature, the affected function, and the call context, not just the file and line number (which shift when the file is edited). Tools that track identity across scans allow teams to see genuine new introductions versus persistent unresolved issues versus regressions.
What Actually Moves the Number
Backlogs shrink when developers can close findings in the same sprint they receive them. That requires two things: findings arriving in the developer's existing workflow (not a separate security dashboard), and enough context attached to each finding that the developer can act without a security specialist on call.
The controls that reliably produce this outcome are: IDE or PR integration (finding shows up where code is written, not in a separate tool), a proposed fix or remediation guidance specific to the language and framework, and an ownership mapping that routes findings to the team who can actually merge the change. None of these require replacing the scanner. They are process layers that translate scanner output into developer action.
The scanner is not the bottleneck. The handoff from scan output to committed fix is.
