Scan every image digest that can still be deployed or that you ship to customers, and skip the rest. Tags are only labels that point at digests, so scope by digest and by status: running, promoted, released, or retained for rollback. Old build artifacts that nothing can pull should be cleaned up, not scanned.
Tags move, digests do not
In a registry, a tag such as 2.4 or latest is a pointer. The same tag can point at a different image next week. A digest, the sha256 hash of the content, always means the same image. The Kubernetes image documentation is explicit that when an image reference has both a tag and a digest, only the digest is used for pulling.
That has a practical consequence. If you scan "the tag", you are scanning whichever digest it pointed at that moment, and your result can silently go stale when the tag is repushed. Store results against digests and record which tags pointed there.
A scoping rule that works
Sort every digest in the registry into one of four groups.
| Group | Scan it? | Cadence |
|---|---|---|
| Running in any cluster | Yes | At least daily against fresh advisory data |
| Released or promoted, can be redeployed | Yes | Daily or weekly |
| Rollback window (last N releases) | Yes | Weekly |
| Untagged, old CI builds, abandoned branches | No | Delete under a retention rule |
Two inputs make this possible. One is a list of what runs, which you can pull from your clusters. The other is a retention policy so the fourth group does not grow forever. We cover that in stale images in your registry.
Cases that trip people up
- Multi-architecture tags point at an index that holds one image per platform. Scan each platform image, not just the index. See scanning multi-arch images.
- Cached or mirrored copies are separate repositories. A digest scanned in one place is the same content in another, so you can reuse the result if the digests match.
- Third party images you pull and rerun belong in scope the day they are deployed, even though you did not build them.
Why not scan everything
It is tempting, and some registries make it the default. The cost is not only compute. A thousand findings on images nobody can run bury the twenty that matter. Teams stop reading the report, and then the report is useless for the images that count.
If someone asks for "full coverage", offer coverage of everything deployable, plus evidence that the rest is cleaned up. That is a stronger answer than a very large number of scanned objects.
A one hour setup
- List the digests running in each cluster and write them to a table.
- List tags created by your release pipeline and resolve them to digests.
- Mark everything else as a deletion candidate and review it with the owning teams.
- Configure scans by digest list, not by repository wildcard.
- Review the list monthly, because new services appear.
Try it yourself
Click through it at your own pace, or open it full screen.
In the demo, notice that findings attach to an image and its packages, which is the unit you want to track.
Where Safeguard fits
Safeguard scans container images and records dependency and SBOM data per image, so you can group findings by deployable image. A free scan shows what the output looks like on one of yours.
Quick check
Do I scan the latest tag?
Scan the digest it points at today, and rescan when the tag moves. Better, deploy by digest so there is no ambiguity.
Can I reuse a scan across registries?
Yes, if the digest is identical, the content is identical. Keep the result keyed by digest.
Sources
Last reviewed: 19 October 2026.
