An unused image in a registry is a finding of lower urgency than a deployed one, because nothing is running it, but it is not zero. Someone can redeploy an old tag by mistake. Separate stored from deployed in your reports, fix the deployed first, and then retire the stored.
Stored versus deployed
Stored image: present in a registry, whether or not anything uses it.
Deployed image: running now in a cluster, a function or a virtual machine.
Registries in a multi-account estate grow quietly. Every build can push an image, and cleanup is rarely automated. A scan of the registry will show thousands of vulnerabilities in images that no one has run for a year, and the noise hides the findings that matter.
Why you still care about stored images
Tags can be reused or changed, as Docker's documentation notes, and a digest pins exact content. If a deployment references a tag, it may pick up an old image after a rollback. Rollback is the very moment when teams reach for the last known good image, which may be the vulnerable one.
A triage method
- Mark deployed digests. Collect digests running in each environment.
- Join with the registry. Images matching a deployed digest are in scope for urgent work.
- Mark recent rollback candidates. The last few releases of each service count as potentially live.
- Leave the rest for retirement. Older images go to a cleanup queue instead of the fix queue.
Reporting view
| Category | Treatment |
|---|---|
| Deployed | Fix by policy deadline |
| Rollback candidate | Fix or retire within the next release cycle |
| Old and unused | Retire after a retention period |
| Unknown | Treat as deployed until proven otherwise |
The unknown row is important. An image that cannot be matched to an owner may be running somewhere you do not see.
Retirement steps
- Set a retention rule, such as keeping the last several releases per service and anything referenced by a deployment.
- Notify owners before deleting.
- Check that no deployment template references an image by tag you are about to remove.
- Record what was deleted and when.
In a hybrid estate
Different sites and accounts often have separate registries and different retention. Inventory them all, and make sure retention rules exist in each, or old images accumulate where nobody looks.
Try it yourself
Open the demo to see how the findings for one image are listed. Then picture the same list for an image that has been idle for a year.
Click through it at your own pace, or open it full screen.
Quick check
Can I ignore findings in images nobody runs?
Deprioritise them, but do not ignore them. Rollbacks can bring old images back into production.
How do I know an image is deployed?
Compare its digest with the digests listed by each cluster, function or machine image source.
Safeguard's container image scanning and asset discovery help you see which images exist and which ones run. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
