Most of a year's dependency backlog is not urgent. The urgent slice is usually small: components with vulnerabilities known to be exploited, flaws in code your application actually reaches, and anything on an internet facing service. Sort by those three signals before you count versions, and the pile shrinks to something a team can act on.
Why the whole list looks urgent
After twelve months, scanners report a large number of findings. Raw counts mix very different things: a flaw in a function you never call, a development only package, a patch release with no security content. Treating all of it equally leads to either panic or paralysis.
Signal 1: known exploited
CISA maintains the Known Exploited Vulnerabilities Catalog, which lists vulnerabilities known to be exploited in the wild, and states that organizations should use it as an input to their vulnerability management prioritization. Match your inventory against it first. Any hit goes to the top, whatever its score.
Signal 2: reachable
A vulnerable package is only a risk if your code can reach the vulnerable function. Reachability analysis traces calls from your code into the library to see whether that path exists. A finding with no path is not harmless forever, but it can safely wait behind the ones that are reachable.
Signal 3: exposed
Ask where the component runs. A service on the public internet that handles untrusted input deserves attention before an internal batch job. Exposure and reachability together are a better compass than a severity number alone.
The triage table
| Signal | Question | Action |
|---|---|---|
| Known exploited | Is it in the KEV catalog? | Fix now |
| Reachable | Does our code call the vulnerable path? | Fix this sprint |
| Exposed | Is the service internet facing or sensitive? | Raise priority |
| None of the above | Old, no known issue | Batch into routine updates |
A realistic sequence
- Export your full dependency inventory with versions.
- Match it to known exploited entries.
- Run reachability on the remainder.
- Mark internet facing services.
- Fix the top group, then batch everything else into weekly or monthly updates.
Keep the batch group moving too. It is not urgent, but it is how the backlog stops growing.
What not to do
Do not close findings just because they are unreachable today. Code changes, and a path that did not exist last quarter might exist next one. Record the reasoning and revisit it on a schedule. Do not use a single severity threshold as the whole policy either, since a medium score on an exploited component can matter more than a high score on dead code.
Set expectations with leadership
Tell leaders the first pass will produce a short urgent list and a long routine list, and that both are normal. The goal is to move the urgent items within days and the routine ones within a planned cadence.
Safeguard's SBOM and dependency scanning lists direct and transitive packages with their versions, and reachability analysis shows which outdated or vulnerable ones your code actually calls. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the full findings list with the reachable subset and see how much smaller the urgent set is.
Quick check
Does an unreachable vulnerability need fixing?
Not urgently, but it should still be tracked and updated in a routine batch, since code paths change.
Is CVSS enough to prioritize?
It is useful input but not sufficient. Add exploitation status, reachability and exposure.
Sources
- CISA Known Exploited Vulnerabilities Catalog
- OWASP Top 10:2021, A06 Vulnerable and Outdated Components
Last reviewed: 19 October 2026.
