Fix first the end-of-life components that face the internet, handle sensitive data, have known exploitable flaws and are cheap to upgrade. Rank every item on those four questions, then work from the top. Do not start with the oldest version. Start with the highest exposure.
Why age is the wrong sort key
An inventory sorted by end date puts a Python 2 script on an internal cron box at the top, and a one year old runtime on your public API in the middle. The script may be the less urgent. Age says how long a gap has existed, not how likely someone is to use it.
Four questions per component
- Exposure: can an outsider reach it, directly or through a service in front of it?
- Data: what does it process or store, and what is the effect if it is taken over?
- Evidence: is there a known vulnerability, and is it being exploited? Check whether it appears in the CISA Known Exploited Vulnerabilities list and what its EPSS score says.
- Effort: how hard is the upgrade, in days?
A component that is exposed, holds sensitive data and has an exploited flaw is an incident waiting to happen, whatever its effort score.
A simple scoring sheet
Give each question a score of 0 to 3, using plain rules.
| Question | 0 | 1 | 2 | 3 |
|---|---|---|---|---|
| Exposure | Offline | Internal only | Partner or VPN | Public internet |
| Data | None | Internal | Customer or business | Credentials or regulated data |
| Evidence | No known issues | Issues, none exploited | Public exploit code | Exploited in the wild |
| Reachability | Not called | Unclear | Called in tests | Called in production path |
Add the scores. Sort descending. Within a tie, take the smaller effort first, because quick wins reduce the list.
Use reachability to cut noise
An end-of-life library often carries several advisories. Many describe code your application never calls. Reachability analysis checks whether the vulnerable function can be reached from your code. It does not make the library supported, but it tells you which gaps are open to attack and which are theoretical, and that affects the order.
Work in batches
- Week one: the top five by score. Write the plan, owners and dates.
- Weeks two to four: schedule the next fifteen into sprints.
- Rest: assign an owner and a date, or an approved exception with a review date.
Report the count of open items by score band each month, so leadership sees the trend and not just a list.
Try it yourself
Open the demo, sort the findings and look at how severity, fix availability and context change what you would do first.
Click through it at your own pace, or open it full screen.
Quick check
Should internal only components wait?
They can rank lower, but not be ignored. Internal systems are reachable after any foothold, so give them a date.
What if the cheapest fix is low risk?
Do it. Quick wins shrink the list and free time for the hard items.
Where Safeguard fits
Safeguard's reachability analysis and dependency scanning help rank findings, and autonomous remediation can open fix pull requests where you have enabled it. It is off by default. Try the free scan.
Last reviewed: 19 October 2026.
