Rescan by digest, not by tag. Record the image digest and its component list when you build, then match that list against current advisories on a schedule. You do not need to rebuild, and you do not need to pull the image again unless the stored list is missing.
Why digests, not tags
A tag such as latest can point to different content tomorrow. A digest identifies exactly one image. If you scan a tag, you might scan something other than what is running. See container image digests vs tags for the background.
Steps
- List what is running. Query your cluster or hosts for the digests of running containers, not the tags in manifests.
- Look up each digest's inventory. If you stored a software bill of materials at build time, fetch it. If not, generate one from the image once and store it against the digest.
- Match against current advisories. Compare the component list with today's data.
- Attach results to the digest. Store findings and the data date, so a result can be reproduced and aged.
- Map digests to owners and services. A finding with no owner is not actionable.
- Alert on new findings only. Compare with the previous run so the same item does not alert daily.
Caching saves time
Because an image digest never changes content, a stored inventory stays valid forever. Only the advisory side moves. That means the daily cost is a match, not a scan. Our post on caching scan results by image digest and lockfile hash goes deeper.
Pitfalls
| Pitfall | Effect |
|---|---|
| Scanning tags | Result may describe a different image |
| Base image drift | A rebuilt image inherits new base packages, so old results do not apply |
| Operating system advisories | Distribution data differs from language ecosystem data |
| Layers removed but not rebuilt | Files can persist in earlier layers |
| Ephemeral jobs | Short lived containers vanish before the next scan |
For short lived workloads, scan at build and at admission, since a nightly scan may never see them.
What to do with a new finding
Decide between three paths. Rebuild with a patched base or dependency and redeploy. Apply a mitigation, such as a configuration change, while a fix is prepared. Or accept the risk with a dated record when the vulnerable code is not reachable. Verify the fix by confirming the new digest is the one running.
Where Safeguard fits
Safeguard offers container image scanning alongside SBOM and dependency scanning, and reachability analysis helps decide whether a finding in an image matters. Try a free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Check what the scan lists inside an image and how findings tie to specific components.
Quick check
Do I have to pull every image again to rescan?
Not if you stored its inventory against the digest. Matching the stored list is enough.
Does a rescan fix anything?
No. It finds. Fixing needs a rebuilt image and a redeploy.
Last reviewed: 19 October 2026.
