A retention policy should never delete an image that is still running anywhere, the last few known good releases you may roll back to, any version you still support for customers, and images that your audit or incident records point to. Everything else is a candidate for expiry.
The protected set, defined
Retention rules are blunt. They match tags, ages and counts, and they know nothing about what your clusters run. So the safest design starts from a list of what must survive, then lets the rule delete the rest.
| Protected class | Why it must stay | How to protect it |
|---|---|---|
| Running images | Pods restart and nodes reschedule, and a pull of a deleted image fails | Check what is deployed before enabling a rule |
| Rollback targets | A bad release needs a fast return | Keep a fixed count of recent release tags |
| Supported releases | Customers on older versions still need patches and reproducible builds | Tag them so a rule can exclude them |
| Evidence images | An audit or incident may need the exact artifact | Keep the digest and records even if the image goes |
Why running images are the dangerous case
Registries do not track which cluster pulled what in a way a cleanup rule can use. Amazon ECR documents that lifecycle rules act on pushed time, pulled time and tag patterns. A rule that expires everything older than a set number of days will happily match the image your oldest, quietest service still runs. That service works until the pod reschedules, then fails with an image pull error at a bad moment.
Before any rule goes live, list the images your clusters and deployment configs reference and compare them with what the rule would remove. Our post on finding which pods run a vulnerable image covers the cluster side of that query.
Make protection visible in the tag
Rules work on tags, so give protected images a tag a rule can recognise. A prefix such as release- for supported versions, kept by one rule, and ci- for throwaway builds, expired by another, makes the policy readable. See a tag naming scheme that makes retention rules possible.
Google Artifact Registry states that when an artifact matches both a delete policy and a keep policy, it is kept. That is a useful pattern: write a broad delete rule, then add explicit keep rules for the protected set. Harbor works the other way round, since its retention rules define what to keep and discard the rest, and multiple rules combine with OR logic.
What about images with known vulnerabilities
An old image with known flaws is a reason to rebuild and redeploy, not a reason to delete it from under a running service. Delete after nothing runs it. If you must stop pulls sooner, block deployment of that tag with a policy and then clean up. Deleting a tag does not change what is already running, as covered in does deleting a vulnerable image tag fix the exposure.
Steps
- Write down the four protected classes for your team.
- Choose tag conventions that let a rule tell them apart.
- Run the registry preview or dry run and compare the result to what is deployed.
- Enable the rule, and review what it removed after the first cycle.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and asset discovery help you see which images and components are actually in use, so you can decide what is safe to expire. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can a retention rule see which images my cluster runs?
No. The rules in the registries documented below match tags, ages, counts or pull times. You need to compare the preview against your own deployed images.
Should I keep every release image forever?
Not necessarily. Keep supported versions and recent rollback targets as images, and keep the digest, SBOM and scan record for the rest.
Sources
Last reviewed: 19 October 2026.
