You open the scanner and it says 2,000 findings. Some critical, lots high, a long tail of medium. Everyone agrees they can't all be fixed this sprint. Most teams then sort by CVSS and start at the top.
That's the wrong order. CVSS tells you how bad a vulnerability could be in general. It doesn't tell you how bad it is for you.
Here's an order that gets the dangerous ones first.
1. Known exploited, first
Start with anything on CISA's Known Exploited Vulnerabilities list. These aren't theoretical. Someone is using them against real systems right now.
This list is usually short. It's also the one auditors and customers increasingly ask about by name.
2. Reachable from your code
Next, the question that cuts the list the most: does your code actually call the vulnerable function?
A library can contain a serious bug in a function your application never uses. The finding is real in the sense that the package is installed. It isn't real in the sense that matters, which is whether an attacker can get to it through your code.
Reachability analysis answers that by tracing calls from your code into the dependency. Findings in code paths you never execute drop down the list. Findings in paths you call every request move up.
3. Exposed to the outside
Among the reachable ones, look at where the code runs. A reachable flaw in an internet-facing API is a different problem from one in an internal batch job that only reads from a queue you control.
Exposure isn't a reason to ignore the internal ones. It's a reason to do the external ones first.
4. Likely to be exploited soon
For what's left, the EPSS score estimates the probability a vulnerability gets exploited in the next 30 days. It's a decent tiebreaker between two findings that look similar on paper.
5. Everything else, on a schedule
The long tail doesn't disappear. Put it on a regular cadence, batch the upgrades by package, and let routine dependency updates absorb what they can.
Why the order matters
The goal isn't a smaller number on a dashboard. It's that the first hour of work goes to the vulnerability most likely to hurt you. Sorting by severity alone spends that hour on whichever finding happens to have the scariest score.
Safeguard shows KEV status, EPSS and reachability next to each finding, so you can sort the list this way from the start. But the order is worth adopting whatever tool you use.
Try it yourself
Click through it at your own pace, or open it full screen.
Put these four findings in the order you'd fix them. Then open the answer.
| Finding | CVSS | On CISA KEV | Your code calls it | Internet-facing |
|---|---|---|---|---|
| A | 9.8 | No | No | Yes |
| B | 7.5 | Yes | Yes | Yes |
| C | 8.1 | No | Yes | No |
| D | 6.5 | No | Yes | Yes |
Quick check
Show the answer
B, D, C, A. B is known exploited and reachable, so it goes first. D and C are both reachable, and D is internet-facing, so D comes before C. A has the highest CVSS but your code never calls the vulnerable function, so it waits. Sorting by CVSS alone would have put A first.
Where does EPSS fit?
As a tiebreaker between findings that look similar after the first three checks.
