For most teams, bake the tools your pipelines need into a versioned runner image and download only what a specific job genuinely varies. Baked tools are reviewed once, pinned and scanned. Tools fetched at job time are fetched again on every run, from whatever the network serves that minute.
The two approaches
Baked. The image build installs compilers, scanners and CLIs at pinned versions. Jobs start fast, need less outbound access, and run the same tool everywhere.
Downloaded at job time. A step runs a download script or a package install. It is flexible, and teams like it because anyone can add a tool without touching the image. It is also the pattern behind many supply chain incidents, because the download happens inside a job that may hold credentials.
Comparison
| Question | Baked into image | Downloaded at job time |
|---|---|---|
| Is the version the same every run? | Yes, if pinned | Only if the script pins it |
| Who reviews the tool? | The image owner, once | Whoever wrote the step |
| Outbound network needed in jobs? | Less | More |
| Can you scan it before use? | Yes, as part of the image | Harder, it arrives mid job |
| Speed | Faster starts | Adds download time per job |
| Flexibility | Needs an image change | High |
When downloading is acceptable
Per-project tools with narrow use, such as a one-off migration utility, can reasonably be downloaded. If you do that:
- Pin an exact version, never a moving label.
- Verify a checksum or signature published by the maintainer, and keep the expected value in your repository.
- Fetch from an internal mirror where you can, so the source is under your control.
- Do not run the download step in a job that holds deploy credentials.
Steps to move from downloaded to baked
- Search your pipeline files for download commands such as curl piped to a shell, wget, or install scripts.
- List the tools and versions each one fetches.
- Add the common ones to the runner image build with pinned versions and checksums.
- Replace the job steps with a version check that fails if the tool differs from what you expect.
- Leave a documented path for adding a tool, with review, so people do not route around it.
What this does for your SBOM and scans
A baked image can be inventoried. Its SBOM lists what a job could execute, and a scan can flag vulnerable tool versions before the image is released. Tools downloaded mid job never appear in that inventory unless you capture them separately, which is why they tend to be invisible in audits.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice how an inventory only lists what it can see, which is the argument for putting tools in the image where they can be seen.
Safeguard's SBOM and dependency scanning can inventory a runner image like any other artifact, and you can try a free scan at gold.safeguard.sh/scan.
Quick check
Does baking tools make images huge?
It can. Keep the image to what most pipelines use and split a second, larger image for specialised teams rather than one image for everyone.
Is curl piped to a shell ever fine in CI?
Treat it as unreviewed code execution with whatever credentials the job holds. Pin and verify instead.
Last reviewed: 19 October 2026.
