Yes, but with different rules. Build and tool images do not serve traffic, so a library flaw there rarely matters for the same reasons. They do run your pipeline with access to tokens, signing keys and source code, so the question changes from "can customers be attacked" to "can the build be taken over". Scan them, and focus on trust and provenance.
Two kinds of images, two threat models
A production image is exposed to inputs from users. A build image is exposed to inputs from your dependencies, pull requests and third party actions or plugins. When a build step runs untrusted code inside a build image, an attacker who controls that code can reach whatever the job can reach.
That is why the image used to run CI jobs counts as part of your supply chain. If someone replaces a tool image with a tampered one, everything built with it is suspect.
Where builder images show up
| Image | Where it appears | Ships to production |
|---|---|---|
| Compiler stage in a multi-stage build | Dockerfile | No |
| CI job image or runner image | Pipeline config | No |
| Tool images for linters, scanners, deploy tools | Pipeline steps | No |
| Test database and service images | Pipeline services | No |
The multi-stage build documentation explains that the build tools of earlier stages are left behind and not saved in the final image. Good: they cannot add findings to your production SBOM. The SBOM attestation documentation adds that by default BuildKit scans only the final stage, so the SBOM reflects what ships.
That also means builder stages are invisible to your normal image scan. If you want them covered, scan them deliberately.
What to check on build images
- Source and pinning. Reference tool images by digest, from a registry you control or trust. See pinning GitLab CI images and tool installs.
- Provenance. Prefer images with known origin. See questions to ask before running a vendor container image.
- Contents. Remove tools the job does not need, since every extra tool is something an attacker can use.
- Credentials. Check which secrets and tokens the job exposes to the image and scope them narrowly.
- Findings. Scan for known flaws, but triage by what the job can reach, not by severity alone.
What severity means here
A critical flaw in an image library that cannot be reached from a build step is low priority. A moderate flaw in the runner agent itself, or in a tool that handles untrusted input like pull request content, is more serious. Weigh findings by exposure to untrusted input and by what privileges the job has.
Keep it proportionate
Do not demand the same SLA as production. Use a looser clock for build images and a stricter rule for provenance and pinning. A monthly refresh is a fair default, and sooner when a tool in the image has an exploited flaw.
Practical steps
- Make a list of every image your pipelines pull, by scanning pipeline files. See how to find package installs hiding in CI scripts and Dockerfiles.
- Move them into a controlled registry with digest pinning.
- Add them to the scan scope with a separate policy.
- Review the list when pipelines change.
Where Safeguard fits
Safeguard scans dependencies and container images and applies gates in pipelines, which can include the images your CI uses. Run a free scan on a tool image to see the output.
Quick check
Do builder stages appear in the production SBOM?
Not by default. BuildKit scans the final stage, so earlier stages need their own scan if you want coverage.
What is the first thing to fix for CI images?
Pin them by digest from a registry you trust. That blocks silent replacement, which is the main risk.
Sources
Last reviewed: 19 October 2026.
