To check for end-of-life software each quarter, list every language runtime, framework, database and container base image you run, look up the support end date for each, and put anything within the next two quarters on the upgrade plan. A spreadsheet and one lookup source are enough.
Why end of life matters
When a version reaches end of life, its maintainers stop publishing fixes. A new vulnerability in that version may never get a patch, so the only fix is to move to a supported version, which is much harder to do in an emergency than on a plan.
Small teams are especially exposed because old runtimes tend to sit in quiet services nobody touches, such as an internal tool or a batch job.
Build the list once
You need one row per thing that has a version and a lifecycle.
| Kind | Examples to list |
|---|---|
| Language runtimes | Python, Node.js, Java, PHP, Go versions in use |
| Frameworks | Web framework major versions |
| Databases and queues | Engine and major version |
| Container base images | The operating system and tag in each Dockerfile |
| Operating systems | Servers, build machines, laptops |
| Build and CI tooling | Runner images and toolchains |
For each row, add the service that uses it, the version, the support end date and an owner. Pull versions from your lockfiles, Dockerfiles and infrastructure definitions rather than memory, since memory is usually wrong about the quiet services.
Find the dates
Use the vendor's own lifecycle page where one exists. Aggregators help too. The site endoflife.date describes itself as documenting end-of-life dates and support lifecycles for many products, and it offers an API and calendar feed. It states that it tracks 485 products at the time of review, and as a community aggregator it should be cross checked against the vendor page for anything that matters.
The quarterly routine
- Refresh the versions (20 minutes). Re-read Dockerfiles, lockfiles and infrastructure code for changes.
- Update the dates (15 minutes). Check each runtime against its support schedule.
- Sort (10 minutes). Colour rows already past end of life red, within two quarters amber, the rest green.
- Plan (15 minutes). Turn each red and amber row into a ticket with an owner and a target quarter.
Red rows come first. If you cannot upgrade a red row soon, record why in your risk list and what limits its exposure, for example no internet access or a strict network boundary. That is a decision, not an oversight.
Make upgrades smaller
The hardest upgrades are the ones that skipped several versions. Moving one supported version at a time, on a schedule, keeps each change small and testable. Pin base image tags to a version you track instead of a floating latest tag, so you know what you are running.
Where Safeguard fits
Safeguard's SBOM and dependency scanning builds an inventory of components, which is the raw material for this list, and its container image scanning shows what a base image brings with it. Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Open a scan result and look at the base image and the packages it pulls in, which is where old runtimes hide.
Quick check
Do we need to track laptops too?
Include operating systems on developer laptops, since those machines hold source code and credentials, but keep them on a separate lighter list.
What if a vendor offers paid extended support?
That is a business decision to record in your risk list. It buys time, not a permanent answer, so still plan the migration.
Sources
Last reviewed: 19 October 2026.
