Find every image built on the affected base by digest, open an update change in each repository automatically, roll out in waves from low to high risk, and track completion on a single list. A base image fix only counts once every dependent image is rebuilt and redeployed.
Step 1: build the dependency map
You cannot update what you cannot list. For each service, record the base image reference from its Dockerfile and the base digest of the last build. If you store an SBOM per image, search it for the vulnerable package and version. If not, scan the running images and read the layers.
Step 2: pin and publish the new base
Publish the patched base under a new tag and a known digest. Pin consumers by digest, because a tag can move. The Kubernetes documentation says digests are immutable and pinning ensures the same code runs every time. Our post on digests vs tags covers the tradeoff with update effort.
Step 3: automate the change
| Approach | Pros | Cons |
|---|---|---|
| Bot opens pull requests per repo | Reviewed, tested, traceable | Needs good CI in each repo |
| Central build template | One change updates all | Hides the dependency; surprises teams |
| Manual tickets | Simple | Slow, easy to forget |
The first is the usual choice. The bot edits the base reference, CI rebuilds and scans, and the owner reviews.
Step 4: roll out in waves
- Wave 0: a service you own with good tests.
- Wave 1: low-risk internal services.
- Wave 2: customer-facing services outside peak hours.
- Wave 3: critical and stateful workloads, with a rollback plan ready.
Watch error rate and startup time after each wave. Base image updates can change libc, shells, certificates and default users.
Step 5: prove completion
Track a single table: service, owner, old digest, new digest, deployed date. Then rescan the cluster. Finished means the vulnerable digest no longer appears in running pods, not that pull requests were merged.
Step 6: stop it recurring
Rebuild on a schedule even without a flagged issue, so stale images do not accumulate. Consider a small set of approved bases rather than dozens, because each extra base multiplies the work.
Try it yourself
Click through it at your own pace, or open it full screen.
Note how a fix with an available version becomes a change someone can review.
Quick check
Should a bot auto-merge base image updates?
Only where tests are strong and rollback is easy. Otherwise require a human review.
How do I know the rollout finished?
Query running pods for the old digest. When none remain, it is finished.
Safeguard's autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try the free scan first.
Sources
Last reviewed: 19 October 2026.
