Image age is the time since a running container image was built. It is a simple, hard to argue with metric because vulnerabilities accumulate in a package set over time. Reporting the age of running images, not just scan counts, shows how far behind your fleet is.
Why age works
A scan result is a snapshot against today's vulnerability data. The image contents do not change, but the data does, so an old image slowly collects findings without anyone touching it. Age captures that drift in one number that does not depend on which scanner you use.
It also nudges the right behavior. The cure for an old image is to rebuild it from an updated base, which clears many findings at once.
How to measure it
- Pull the list of images running in production from your orchestrator or registry.
- For each, read the build timestamp from image metadata.
- Compute age as today minus build time.
- Group by service, then report the median and the oldest.
- Add the base image version for each so you can see shared causes.
| View | Question it answers |
|---|---|
| Median age | How current is the fleet? |
| Oldest running image | What is the worst case? |
| Age by base image | Which base needs updating first? |
| Images older than target | How many breach policy? |
Set a rebuild target
Choose a maximum age by exposure. Internet-facing images get a shorter window than internal batch jobs. Write the window in policy and put it on the dashboard. A rebuild cadence, such as a scheduled weekly or monthly rebuild, is easier to meet than reacting to every advisory.
Watch for traps
- Build date is not patch date. An image built yesterday from an old base layer can still contain old packages. Track the base image version too.
- Tags that move. If a tag like latest is reused, the age you read may not match what is running. Record digests.
- Long lived containers. A rebuilt image does nothing until it is deployed. Measure age of what is running, not what is in the registry.
- Missing metadata. Some images lack timestamps. Report the share without data.
Pair it with findings
Age predicts, findings confirm. Show both: age bands on one axis and open findings per band on the other. Leaders see that older bands carry more findings and understand why a rebuild cadence matters.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open an image scan and look at the layers and packages, which is where age turns into findings.
Quick check
Is a newer image always safer?
Usually fewer known issues, but not guaranteed. A new image can pull in a new vulnerable package. Scan every build.
Should we rebuild on a schedule or on advisories?
Both. A schedule keeps the fleet current by default, and advisories trigger faster rebuilds for urgent items.
Last reviewed: 19 October 2026.
