Treat routine base image refreshes within the same release as a pre approved standard change, with automated tests as the guardrail, and keep full review for moves to a new major release. That keeps patching fast and still leaves a record a reviewer can follow.
Why a ticket per rebuild backfires
If every base refresh needs a manual approval, teams batch them. Batches are bigger, riskier and later. The security fix that could have shipped on Tuesday ships three weeks on. A change process that slows patching has defeated its own purpose.
The opposite failure is no record at all. When something breaks after a rebuild, nobody can say what changed.
Two classes of change
| Class | Example | Handling |
|---|---|---|
| Routine refresh | Same release, fresh pull, new digest | Pre approved standard change, automated gates |
| Release move | Debian 12 to 13, Alpine 3.21 to 3.22 | Normal change with a plan, pilot and rollback |
| Variant move | Full image to a slim variant | Normal change, test for missing tools |
| Vendor image swap | Different publisher | Intake review, plus normal change |
The line sits at risk, not at who is asking.
What makes a standard change defensible
A standard change is acceptable when it is low risk, repeatable, and has controls. For a routine refresh, the controls can be:
- The base is on the approved list, so the source was reviewed once.
- The build pins the base by digest, so the change is a visible diff in a pull request.
- Tests run and must pass before deploy.
- A scan runs and the result is stored, so a new critical finding can block the rollout.
- Rollback is one redeploy of the previous digest.
If all five hold, a reviewer can see that the change was controlled even without a human approving each one.
Evidence to keep
For each refresh keep the pull request or pipeline run, the old and new digest, the test result and the scan or SBOM. Change management evidence often exists already in your repository history. The point is to be able to retrieve it for any date.
When to pull the emergency lever
An advisory against your base may justify an out of cycle rebuild. Write down in advance who can approve it, how fast, and what testing can be shortened. Doing this in calm conditions is much easier than in the middle of an incident.
Write the policy in four lines
State the class of change, the guardrails required, who owns the approved list, and the review date for the policy. A policy that short gets read, and gets followed.
Where Safeguard fits
Safeguard policies and gates can hold a rebuild when a new finding crosses your threshold, and stored scan and SBOM records supply the evidence trail. Autonomous fix pull requests are off by default, and every category starts on Manual, so a human stays in the loop until you decide otherwise.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a gate decides pass or fail on a change, which is the guardrail for a routine refresh.
Quick check
Do auditors accept pre approved changes?
Reviewers generally look for a defined process, applied consistently, with evidence. A written standard change with guardrails and retrievable records is something to show them. Confirm with your own auditor what they expect.
Who approves the base image list?
Usually a platform or security owner, reviewed on a fixed cycle, with a documented intake step for new entries.
Last reviewed: 19 October 2026.
