Your vulnerability scanner just reported four thousand findings across the codebase. How do you actually triage that?

Short answer

Triage a vulnerability scanner backlog by asking whether the issue is exploitable, reachable in production, on a critical asset, and fixable at a shared root cause. Block releases only for the highest-risk reachable findings; track the rest with owners and aging rules.

Why the raw list is the wrong starting point

Four thousand findings sorted by the scanner's own severity field is a trap disguised as a plan, because the severity score is context-free: it describes the vulnerability in the abstract, not its exposure in your system. A critical-rated deserialisation flaw in a library your build depends on but never actually invokes at runtime is lower real risk than a medium-rated flaw in code that parses attacker-controlled input on an unauthenticated endpoint. Working the list in the order the tool printed it means spending the first day on findings a determined attacker could never reach, while the one exploitable path sits unaddressed at position two thousand.

The first useful move is applying a reachability filter. Static analysis and dependency scanners routinely flag code paths that are unused, feature-flagged off, or reachable only from an internal admin tool nobody exposes externally. Some SCA tools now do call-graph analysis to tell you whether the vulnerable function in a dependency is actually invoked; where that isn't available, a manual pass on the highest-severity findings to check whether the vulnerable code path is even reachable from an entry point an attacker controls does more to shrink the real backlog than any amount of severity sorting.

Grouping collapses the backlog before you fix anything

The second move, and the one that produces the fastest visible progress, is grouping by root cause rather than treating four thousand findings as four thousand independent problems. A single outdated logging library referenced transitively by a dozen internal modules can produce dozens of nearly identical SCA findings; bumping one version resolves all of them in one pull request. Similarly, a SAST tool flagging the same unsanitised-input pattern across forty controller methods usually indicates one missing validation layer rather than forty separate bugs, and the fix is a shared input-handling change rather than forty patches.

4,000 raw findings
  -> deduplicate by CVE / rule id + dependency        ~ 4,000 -> 900
  -> filter unreachable code paths                    ~  900 -> 340
  -> group remaining by root cause (shared library,
     shared code pattern, shared misconfiguration)    ~  340 -> ~60 real fixes

That collapse from four thousand to roughly sixty distinct pieces of work is the actual triage output, and it is what makes the backlog something a team can commit to rather than something that gets quietly ignored.

Setting a policy, not just doing a one-time pass

The trap specific to this scenario is treating the backlog as a single event to clear rather than a stream that will refill. Without a policy, the next scan produces another four thousand findings and the team repeats the same manual triage from scratch.

A durable answer defines two separate thresholds: a release-blocking bar — typically critical severity plus confirmed reachability, or any finding in a category the organisation has decided is never acceptable, such as hard-coded secrets — and a tracked-debt bar for everything above a minimum severity that does not block a release but is owned, dated and revisited on a cadence. Anything below the tracked-debt bar is accepted risk, and accepting it explicitly, with a named owner and a reason, is different from it silently sitting in a report nobody reads.

The last piece, easy to skip under time pressure, is assigning ownership. A backlog with no owner decays back to unmanageable within weeks regardless of how well the first triage went, because new findings arrive continuously from every subsequent scan and dependency update. The strong answer names a rotating or dedicated owner responsible for the triage step itself — deduplicate, filter, group, apply the policy — as a recurring process, not a project with an end date.

The scanner produces a list; triage is deciding which items on it represent an attacker's actual path, and that decision is made with reachability and grouping, not with the severity column alone.

---

© 2026 Preptima. Originally published at preptima.com.