To test a base image upgrade, build the new image from a pinned tag or digest, compare its package list and scan results against the old image, run your smoke and integration tests against it, then roll it out in stages. The risk is not your code. It is the operating system layer beneath it.
What actually changes
When you move to a newer base image, you may change more than security fixes: system libraries, the C library, the shell, certificates, timezone data, default users and file paths. A patch to a shared library can alter behavior in your app without touching a line of your code. Switching to a different base family, for example from a general distribution to a minimal one, changes more again, because tools you relied on may be missing.
Step 1: Pin what you compare
Reference both images by digest, not by a moving tag. A tag such as latest or a major version label can point to a different image tomorrow, which makes a comparison meaningless. Record the old and new digests in the pull request.
Step 2: Compare the contents
Generate an SBOM for each image and diff them. Look at three things.
| Diff | What to ask |
|---|---|
| Packages added | Do we need them, and what do they bring in |
| Packages removed | Does our app or startup script call them |
| Version changes | Any major jump, especially libc, TLS, or the language runtime |
Then scan both images and compare findings. A good result is fewer findings overall and none new. If a new finding appears, check whether the vulnerable package is actually used by your container. See Alpine versus Debian base images for how base choices differ.
Step 3: Run behavior tests inside the new image
- Build your application image on the new base using your normal pipeline.
- Start it with production-like configuration and run the smoke test. See what a smoke test should check.
- Run integration tests that touch TLS, DNS, file permissions, timezone handling and locale, since base images affect these.
- Check the container runs as the same user and can write only where intended.
- Check startup time and memory against the old image.
If the new base is a minimal image without a shell or package manager, confirm that health checks and entrypoint scripts do not rely on them.
Step 4: Roll out in stages
Deploy the new image to a small share of instances, compare error rate, latency and restarts against the control, then widen. Kubernetes Deployments update pods by rolling update and keep revision history so you can return to the previous revision. A rollout is triggered when the pod template changes, such as a new image. Keep the old image in your registry until the new one has run through a full traffic cycle.
Step 5: Record and repeat
Save the SBOM diff, scan comparison and test results with the change record. Schedule the next base refresh on a cadence rather than waiting for an incident, so each upgrade is small.
Common failure causes
- Missing certificate bundle, causing outbound TLS errors.
- Different default user or file ownership, causing write failures.
- Different libc, breaking native extensions built for the old one.
- Timezone or locale data absent from a slim image.
- A removed utility that an entrypoint script called.
Safeguard scans container images and lists their components, so you can compare old and new images and see which findings are reachable from your code. Try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings map to image layers, which tells you whether the base or your own layer introduced them.
Quick check
Should I use a moving tag for the base image?
Use a pinned version or digest for builds you can reproduce, and refresh it deliberately on a schedule with the tests above.
Is a smaller base image always safer to upgrade to?
It usually has fewer packages to patch, but it may lack tools your scripts expect. Test startup, TLS and file access before rollout.
Sources
Last reviewed: 19 October 2026.
