Triage by exposure first, reachability second, fix availability third and ownership last, instead of sorting only by severity score. A legacy monorepo can return thousands of findings on day one, and severity alone gives you a list too long to act on.
Why severity alone fails
A severity score describes a flaw in general. It does not say whether your code calls the vulnerable function, whether the service faces the internet, or whether a fix exists. Sorting only on the score puts hundreds of items at the top and tells a team nothing about where to begin.
The order
- Exposure. Separate services reachable from outside the company from internal tools and batch jobs. Findings in exposed services come first. Your asset inventory or load balancer configuration answers this.
- Reachability. Within each group, ask whether the vulnerable code is actually called. A finding in a function nobody invokes is lower priority than one on a live request path.
- Known exploitation. Check whether the vulnerability is listed as exploited in the wild, using a public catalog. Those jump the queue regardless of other factors.
- Fix available. Items with a safe upgrade can be handled quickly and show progress. Items without one need a mitigation decision.
- Ownership. Route each remaining item to a team. If there is no owner, that is its own work item.
A worked sorting table
| Exposure | Reachable | Fix available | Action |
|---|---|---|---|
| Internet facing | Yes | Yes | Fix this sprint |
| Internet facing | Yes | No | Mitigate now, track a fix |
| Internet facing | Unknown | Yes | Upgrade if low risk; confirm reachability |
| Internal | Yes | Yes | Schedule within the quarter |
| Internal | No | Any | Backlog; revisit when exposure changes |
Treat "unknown" as its own bucket. It is honest, and it prevents unproven claims from sliding into either extreme.
Keep the first batch small
Take the top twenty items, not the top two thousand. Assign them, set a date, and report the result. A team that finishes twenty items trusts the process; a team handed two thousand starts a spreadsheet and stalls.
Put everything else into a baseline: known, dated, and not blocking. That lets you gate new findings from the start without pretending the old ones do not exist.
Check your assumptions weekly
Reachability tools can be wrong in either direction, especially with reflection and dynamic loading. Pick a few findings marked unreachable and have a developer confirm. If they find one that is reachable, adjust your rules and say so.
Try it yourself
Click through it at your own pace, or open it full screen.
Compare the list before and after reachability filtering, and think about which items would land in your first twenty.
Where Safeguard fits
Safeguard's reachability analysis helps separate called code from unused code, and its policies let you gate new findings while the baseline is worked down. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Should critical severity ever be ignored?
No, but it should be read with context. A critical flaw in unreachable code on an internal tool can wait behind a high flaw on an exposed path.
What if we cannot tell which services are exposed?
Then building that list is your first task. Even a rough one from load balancer or ingress configuration is enough to start.
Last reviewed: 19 October 2026.
