Rebuild your CI runner image on a fixed schedule, such as weekly, and also whenever the base image or an installed tool ships a security fix. Ephemeral runners start from the image every time, so a stale image means every job starts with the same known weaknesses.
Why the image becomes the thing to patch
On a monolithic CI server you patched the machine. With ephemeral runners the machine is thrown away after each job, so patching a running runner achieves nothing. The only place a fix survives is the image the next runner starts from. That moves your patching work from servers to a build pipeline for the image itself.
This is good news. A rebuild is repeatable, reviewable and testable, which a hand-patched agent never was.
A cadence that works
- Scheduled rebuild. Weekly is a common starting point. Pick a day, run it automatically, and let it pull the current base image rather than reusing cached layers.
- Event rebuild. Rebuild when a vulnerability affecting the base image, a language runtime or a build tool is published and a fixed version exists.
- Break glass rebuild. If a tool in the image is found compromised, rebuild without waiting, and rotate any credentials that image could have reached.
Tune the schedule to how fast your base image publishes updates and how much of your estate depends on the image. A single shared image used by hundreds of pipelines deserves a tighter cadence than one used by a single team.
Make rebuilds safe to roll out
- Build the image in its own pipeline with a version tag and a recorded digest.
- Scan the new image and compare findings against the last one.
- Run a small set of canary pipelines against the new tag before the default moves.
- Keep the previous image available so a bad release can be rolled back quickly.
- Record which image digest each job used, so you can answer "which builds ran on the vulnerable image?" later.
Pinning by digest rather than by a moving label keeps a rebuild from reaching every pipeline at once. It also gives you an audit trail.
What a rebuild does not cover
A fresh image fixes what is inside it at build time. It does not fix dependencies that your jobs download later, and it does not fix findings that appear after the build. Rescan published images on a schedule, not only at build time, because new advisories arrive after an image is cut. See a clean build-time scan is a snapshot for why.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are tied to image layers, since that tells you whether a rebuild or a package change will remove them.
Safeguard's container image scanning and continuous monitoring can be pointed at your runner image the same way as any other image. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is weekly too often?
Not if the rebuild is automated. The cost is mostly in review and rollout, so automate the scan and canary steps and weekly becomes routine.
Can I just run apt upgrade inside the running job?
You can, but it adds time to every job and gives each job a different package set. Rebuild the image instead so every runner starts identical.
Last reviewed: 19 October 2026.
