Run scans as separate jobs on fresh runners, fed by the build output, rather than as extra steps inside the build container. A separate job gets only the access a scan needs, fails independently, and can be required by policy. Keep source level scans early and image scans after the image is built.
The three placements
- Inside the build container. Simple, but the scanner shares the filesystem, credentials and tools of the build. A compromised build step can alter scanner config or output.
- A separate job in the same pipeline. The scan starts on its own runner, pulls the artifact or image by digest, and reports pass or fail. This is the usual fit.
- A sidecar or external service. Useful for long running monitoring, such as rescanning a registry, but not a replacement for a gate on the change.
Which scan goes where
| Scan type | Input | Best placement |
|---|---|---|
| Dependency scan and SBOM | Lockfiles and manifests | Early job, runs in parallel with the build |
| Static code analysis | Source | Early job on the pull request |
| Container image scan | Built image by digest | After the build, before promotion |
| API or web scan against a running app | A deployed test instance | Later job in an isolated environment |
| Registry rescan | Images already published | Scheduled, outside the pipeline |
Why separate jobs help in an ephemeral setup
Each job starts clean, so a scan cannot be skewed by leftovers from the build. The scan job also needs fewer secrets, usually none beyond read access to the artifact. And a required job can be enforced by branch rules, which an in-build step cannot.
One caution: scanners rely on vulnerability data. A fresh runner starts with whatever database the image or cache holds, so a stale one can report clean results for known issues. Stale vulnerability data in CI scan caches and ephemeral runners explains how to refresh it.
Steps to set this up
- Have the build job publish the image or artifact and output its digest.
- Start the scan job with that digest as input, never a moving label.
- Give the job read only access to the artifact and no deploy credentials.
- Fail the job on the policy you have agreed, and require it before merge or promotion.
- Store the report with the build record so it can be retrieved later.
- Schedule a separate rescan of published images, since new advisories appear after the build.
What a gate should decide
Blocking on every finding stalls delivery, so pick thresholds on severity, whether a fix exists and whether the vulnerable code is reachable. Revisit them after a month of real results.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through a scan and look at what the report ties each finding to, since that is the data a gate would act on.
Safeguard supports container image scanning, reachability analysis and policy gates in CI, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Is one combined scan step simpler and good enough?
For a small team it can be a start. As soon as the pipeline holds deploy credentials, separate the scan so it cannot be influenced by the build.
Do I still need a registry scan if I scan in CI?
Yes. CI scans a moment in time. A registry rescan catches advisories published later.
Last reviewed: 19 October 2026.
