Do both, in this order: scan in CI first so bad builds are stopped before they are pushed, then add registry scanning so images that were pushed some other way, or went stale, are still covered. CI gives fast feedback; the registry gives a complete and continuing view.
What each location sees
| CI scan | Registry scan | |
|---|---|---|
| Timing | Before push | After push, repeated |
| Coverage | Images your pipeline builds | Every image in the registry |
| Can block a release | Yes | Only through later policy |
| Catches new advisories on old images | No | Yes, if it rescans |
| Sees images pushed by hand or other tools | No | Yes |
| Feedback to the developer | In the pull request | Later, by alert |
Why CI alone leaves gaps
A pipeline scan is a single moment. Images pushed from a laptop, built by another team or mirrored from outside never pass through it. Old images keep running long after their scan. A registry scan covers all of them, and repeating it picks up new advisories.
Why the registry alone is too late
If the first scan happens after push, the bad image already exists and can be pulled. Developers also get the news hours later, away from the change that caused it. CI puts the message where the fix is made.
A combined setup
- CI scans the built image before push and fails on your policy.
- The registry rescans on a schedule using stored inventories.
- Production deploys only by digest from approved repositories.
- An admission rule rejects images without a recent passing result.
- Findings from both routes land in one list with one owner per service.
Registry questions people ask
Does scanning slow pulls? Usually not; it works on stored content. Does it cover every tag? Check, because some tools scan only the latest push per tag. What about untagged images? They still take space and may still be pulled by digest, so include them or delete them. And retention: remove images you will never deploy, because every one is something to scan and explain.
Try it yourself
Click through it at your own pace, or open it full screen.
Imagine the same scan running in CI and again a month later, and note which findings would be new.
Quick check
If I only have time for one, which?
CI, because it stops new problems. Add scheduled rescans of deployed images soon after.
Do registry scans replace policy gates?
No. A gate decides what is allowed to deploy; a scan produces the data it uses.
Safeguard applies policies and gates to scan results and scans dependencies and SBOMs; you can try the free scan.
Last reviewed: 19 October 2026.
