To check whether a container base image is end of life, read the operating system release inside the image, find that release on the vendor's support calendar, and compare it with today's date. Then check the language runtime in the image, since it has its own calendar. Rebuild on a supported base if either is past its date.
Why images go stale
An image is a snapshot. When you build FROM ubuntu:20.04 and never rebuild, the OS inside stays 20.04 forever, even after its standard maintenance ends. Pinned tags keep builds repeatable, which is good, but they also freeze the calendar.
Two layers matter. The operating system layer follows a distribution calendar. Debian, for example, lists a regular support period followed by LTS and extended LTS phases. Ubuntu 20.04 standard security maintenance ended in May 2025, and coverage now requires a paid subscription. The runtime layer, such as a Node.js, Python or Java version, follows its own project policy.
How to read what is inside
Run a throwaway container and print the release file:
docker run --rm IMAGE cat /etc/os-release
docker run --rm IMAGE sh -c "node -v || python3 --version || java -version"
Replace IMAGE with the image reference. The first command prints the name and version of the operating system. The second prints whichever runtime is present.
For a whole registry, script the same check across tags, or scan each image to produce a software inventory and read the OS and runtime entries from it.
Compare with the calendar
| Layer | What to read | Where to check |
|---|---|---|
| Operating system | /etc/os-release | The distribution's release page |
| Language runtime | Version command | The project's support page |
| Application packages | Lock file or SBOM | Each package's maintenance status |
Check the vendor page for the date. Debian's release page shows that dates can be revised, so confirm before escalating.
Fix it
- Pick a supported base. Prefer a version that has at least a year left, and say why in the Dockerfile comment.
- Use the smallest image that works. A slimmer base has fewer packages to patch.
- Rebuild on a schedule, such as weekly, even without code changes. That pulls in fixed packages.
- Pin by digest for repeatability, and update the digest through a routine, reviewed change.
- Add a policy check in CI that fails a build when the base is past its end date.
- Track which services use each base, so a deprecated image has a known list of owners.
Do not forget what already runs
Images sitting in the registry are not the same as images running in production. List the images running in your clusters and compare. Old jobs and sidecars are the usual surprises.
Try it yourself
Open the container scan demo and look at where the image's operating system and packages appear in the results.
Click through it at your own pace, or open it full screen.
Quick check
Does rebuilding an image fix an end-of-life OS?
No. If the base release is past its end date, a rebuild just reinstalls the same unsupported release. You must change the base.
Should I use the latest tag?
It makes builds unpredictable. Pin a specific supported version or digest and update it on purpose.
Where Safeguard fits
Safeguard's container image scanning lists the operating system and packages inside an image, and its policies and gates can fail a build that does not meet your rules. Try the free scan.
Sources
Last reviewed: 19 October 2026.
