Most vulnerability backlogs are sorted by CVSS score. It is the obvious default: the number arrives with the finding and sorting by it requires no work. It is also close to the least useful ordering available, because CVSS describes a vulnerability in isolation and you do not run software in isolation.
What CVSS is and is not
CVSS is a severity score. It answers: if this vulnerability were exploited under ideal conditions for the attacker, how bad would the outcome be?
It deliberately says nothing about whether the vulnerable code runs in your deployment, whether the component is reachable from the internet, whether an exploit exists, or what the affected system can access.
Why that matters in practice
A critical-rated flaw in a library function your application never calls is not an emergency. A medium-rated flaw on an unauthenticated, internet-facing endpoint that fronts your customer database is.
The three questions worth asking
Is it reachable?
Can attacker-controlled input actually arrive at the vulnerable code? For dependencies this means call-graph reachability: is the vulnerable function invoked at all? For first-party code it means data-flow: does an untrusted source connect to the dangerous sink without an effective guard in between?
Reachability analysis typically removes the large majority of dependency findings.
Is it exploitable?
Reachable is not the same as exploitable. Exploitability asks whether the preconditions hold: the vulnerable version, the specific configuration, the authentication state required, and whether a public exploit exists.
What is the blast radius?
If it were exploited, what does the compromised component reach? A service running with scoped, read-only credentials in an isolated account is a different proposition from one holding a long-lived admin key.
Turning this into an ordering
Combine the three into a single question — what could an attacker actually achieve here, today, and how much would it cost us — and the backlog reorders itself sharply. Findings that survive all three filters are typically a small fraction of the original list, which is what makes them actionable.
Keep the rest, but out of the way
Filtered findings should not be deleted. Reachability changes when code changes, so a finding that is unreachable today may not be next quarter. Track them; just stop putting them in front of engineers.
Closing the loop
A prioritisation model only pays off if the top of the list gets fixed. Measure time from detection to merged fix for the findings you deemed critical. If that number is not moving, the bottleneck is remediation capacity, not ranking.