Deleting old images is housekeeping with a security benefit, not a security control by itself. It reduces what can be pulled by mistake, but it does not fix anything already running. Treat it as support for patching and inventory, not a substitute.
Myth versus fact
| Myth | Fact |
|---|---|
| Deleting an old image removes its vulnerabilities | It removes a pullable copy. Running containers and cached nodes keep the image |
| A smaller registry is a safer registry | Fewer images means less to track, which helps, but safety depends on what you deploy |
| Retention rules protect production | They know tags and ages, not what runs. They can delete a live image |
| Old images can be deleted without telling anyone | Digest pinned systems and rollbacks may depend on them |
| Once deleted, we can restore it | Often not. Azure states deleted image data is unrecoverable |
| Cleanup satisfies a compliance requirement | It supports a retention policy, but you still need evidence and a defined policy |
What cleanup does give you
Retention does improve hygiene in real ways. A developer who pulls the wrong old tag has less chance of doing so. Scans and inventories cover fewer artifacts. Alerts about a base image flaw touch fewer repositories. The attack surface that is registry content gets smaller.
Those are modest gains. They matter most when combined with the controls that actually reduce risk: rebuilding on patched bases, redeploying, and blocking known bad versions at deploy time.
What cleanup does not do
It does not patch. It does not stop a running pod from using an image. It does not remove copies in mirrors or caches. Our post does deleting a vulnerable image tag fix the exposure walks through those cases.
It also does not erase what is already known. If a flaw was disclosed for a version, the advisory stays regardless of whether your registry still holds the image.
Using retention well
- Patch and redeploy first, using inventory to find what runs a flawed image.
- Block the flawed tag from deploying with a policy.
- Then let retention remove old copies on schedule.
In that order, cleanup is safe and tidy. In the opposite order it can strand a service.
Retention is also a policy decision
How long you keep release images touches audit, support and customer commitments. Write it down, and see how long to keep container scan evidence for audits.
Try it yourself
Click through it at your own pace, or open it full screen.
Follow a finding from detection to fix. Notice that closing it means patching and redeploying, not just removing an old artifact.
A fair way to describe it in a questionnaire
If a buyer asks whether you manage old images, say what is true: you apply retention rules to limit what can be pulled, you protect release images, and you patch and redeploy rather than rely on deletion. Avoid wording that implies cleanup removes vulnerabilities, since a careful reader will know it does not.
Quick check
Should I still run retention?
Yes, for hygiene and inventory size. Just do not rely on it as a vulnerability fix.
What fixes a vulnerable running image?
Rebuild on a patched base or dependency, then redeploy. Cleanup comes afterward.
Sources
Last reviewed: 19 October 2026.
