There is no universal number, but a workable limit is a rebuild at least monthly for anything internet facing, and a hard review point at 90 days for everything else. Age is a proxy: it tells you how long patches have been accumulating upstream without reaching your running workload.
Why age matters even when the scan is clean
A vulnerability scan only knows about flaws that have been published. An image built eight months ago has gone eight months without picking up any fix, including fixes for problems that are not yet public when it was built. Age therefore predicts exposure to the next advisory better than today's finding count does.
Publishers think the same way. Microsoft's guidance for Windows Server containers says the base images are rebuilt each month with the updates, because containers have no servicing stack of their own and cannot be patched from inside. Updated images are published on the second Tuesday of each month, per that page. The general idea carries over: an image is a snapshot, and refreshing means rebuilding.
What counts as age
Two clocks run, and you want both.
- Build age: when your image was built.
- Base age: when the base image digest you built on was published.
A service rebuilt last night on a six month old pinned base is fresh in the first sense and stale in the second. Report both.
Setting limits
| Environment | Suggested limit on build age | Action when exceeded |
|---|---|---|
| Internet facing production | 30 days | Open a rebuild ticket automatically |
| Internal production | 90 days | Review in the monthly meeting |
| Staging and test | 90 days | Warn only |
| Dev and sandbox | No limit | None |
Treat these as starting points to tune, not a standard. Pick limits you can actually meet, then tighten.
How to measure it
- Read the creation timestamp from the image config. Most registries and CLIs expose it.
- Resolve the base digest from the build record or SBOM and look up when it was published.
- Join with what runs in each cluster so you only report on deployed images.
- Chart the age distribution. The tail matters more than the median.
Watch out for one trap. Reproducible build setups can set the timestamp to a fixed value, so creation time may read as the epoch. Use the build system record in that case. See reproducible container builds.
What to do about old images
Do not patch in place. Rebuild from a current base, run your tests, and redeploy. Automate the rebuild with a scheduled pipeline so age resets without a human remembering. For the base, publish new digests on a cadence and nudge services to adopt them. See rolling out a patched base.
An old image that is deliberately frozen, such as a regulated workload under change control, needs a written exception with an owner and an end date, not silence.
Where Safeguard fits
Safeguard records SBOM and dependency data per image, which gives you package versions to compare against current advisories, and policies can warn or block on findings. Try a free scan on one image.
Quick check
Is a clean scan enough to keep an old image?
No. A clean scan covers known flaws only. Age shows how long you have gone without upstream fixes, so keep a rebuild cadence regardless.
Should we just run apt upgrade in running containers?
No. Changes made inside a running container are lost on restart and are not recorded in the image. Rebuild and redeploy.
Sources
Last reviewed: 19 October 2026.
