Read the operating system release named in your base image tag, then check that release's support dates on its project page or a tracker. If standard security support has ended, move to a newer release or confirm what long term support covers. A scanner only reports flaws that someone still publishes fixes for.
Why this matters
An image on an unsupported release keeps working. It just stops receiving fixes, so new flaws pile up with no patch to rebuild into. Rebuilding more often does not help if the archive has nothing new.
A real example: Debian
One public tracker, endoflife.date, listed these Debian dates when we checked on 19 October 2026.
| Release | Security support | Long term support ends |
|---|---|---|
| 13 (Trixie) | Until 9 Aug 2028 | 30 Jun 2030 |
| 12 (Bookworm) | Ended 11 Jul 2026 | 30 Jun 2028 |
| 11 (Bullseye) | Ended 14 Aug 2024 | Ended 31 Aug 2026 |
| 10 (Buster) | Ended 10 Sep 2022 | Ended 30 Jun 2024 |
The page notes that long term support is run by a separate group, not the Debian security team, and that not all packages are covered. So an image built on Bookworm today sits in long term support, which is narrower than full security support. Dates change, so check the tracker and the Debian project before you decide.
Steps
- List the base images in every Dockerfile, including those in build stages and sidecars.
- For each, find the OS release behind the tag. Codename tags such as a release name are clearer than latest, which hides the release.
- Look up standard support and extended support dates.
- Mark anything inside twelve months of its end for a planned upgrade.
- Record owner and target date in your backlog.
- Re-run the list every quarter.
Watch the tag
Tags named latest or a bare version can jump to a new OS release when upstream moves. That is useful for freshness but can break builds. Pinning to a release name and a digest gives control, and you then own the move. See pinning base image digests without falling behind.
Language runtime images too
Your base may be a language image, such as one for a runtime version. The runtime has its own support window, and it sits on top of an OS release with another. Check both. A supported runtime on an unsupported OS still leaves system libraries unpatched.
What to tell auditors and buyers
State the policy, not just the current state: images move off a release before standard security support ends, checked quarterly, with exceptions recorded. That is a claim you can evidence with the inventory and the dates.
Quick check
Does a clean scan mean my base image is supported?
No. A scan reports known flaws with published data. An unsupported release can look clean simply because no one is fixing or documenting new problems for it.
Is long term support the same as security support?
Not exactly. For Debian, the tracker notes it is handled by a separate group and may not cover all packages. Read the scope before relying on it.
Safeguard
Safeguard does SBOM and dependency scanning, and its policies and gates can run in CI so a bad image does not reach production. You can try a free scan before deciding anything.
Sources
Last reviewed: 19 October 2026.
