Do both if you can. A scan in CI gives fast feedback and can block an image before it is published. A scan in the registry rechecks images already stored, because new advisories appear after the build. If you must pick one, start with CI and add recurring rechecks soon after.
What each does
CI scan: runs after the image is built, inside the pipeline. The result is tied to a commit and a developer who can fix it.
Registry scan: runs on stored images, on a schedule or when advisory data changes. It covers images that no pipeline will touch again.
Comparison
| CI scan | Registry scan | |
|---|---|---|
| Timing | At build | After push, repeatedly |
| Can block a release | Yes | Only through deploy policy |
| Finds new advisories on old images | No | Yes |
| Developer context | High | Low |
| Covers images not built by you | No | Yes, if pulled into the registry |
The gap if you only scan in CI
An image built in March passes. In September a flaw in one of its operating system packages is published. No build runs, so nothing reports it, yet the image is still running. Recurring scans close that gap.
The gap if you only scan in the registry
Problems are found after the image exists and maybe after it ships. Developers get tickets days later, without context.
Setup steps
- Add an image scan step after build, with a policy that blocks only on severity and fix availability you agree on.
- Generate an SBOM at build time and store it with the image.
- Enable recurring registry rechecks.
- Route registry findings to the owning team through your inventory.
- Rebuild from updated base images on a cadence, not only when alerted.
Common mistakes
Teams often scan only the final image and miss where an issue came from. Learn to separate findings in the base image from those in your own layers, because the fix differs: updating a base image versus changing your packages. Also remember that images from outside, such as a vendor appliance, never pass through your pipeline. Pulling them into a scanned registry before use gives you a view you would otherwise lack.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings split between the base image and your own layers.
Quick check
Does a clean scan mean the image is safe?
No. It means no known issues matched at that time. New advisories can change the result.
Should I block on every vulnerability?
Usually not. Start with a rule such as fixable and high severity, then adjust as noise falls.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, policy gates and asset discovery. Try the free scan.
Last reviewed: 19 October 2026.