Choose the smallest maintained base image that runs your service, pin it by digest, rebuild on a schedule and scan every build. A new service carved out of a monolith should not inherit the monolith's old operating system image just because that is what the team knows.
Why this matters at extraction time
Extraction is a rare chance to reset. The monolith may run on an old, large image with many packages installed for features the new service will never use. Each package is a potential finding. Starting with a fresh, small image removes most of them before the first scan.
What to weigh
| Factor | Question to ask |
|---|---|
| Size and contents | Does it contain a shell, compilers and package managers you do not need? |
| Maintenance | Is it rebuilt regularly with security updates, and by whom? |
| Compatibility | Does your runtime and native libraries work on it? |
| Debuggability | Can your team troubleshoot without tools that were removed? |
| Provenance | Do you know who publishes it and can you verify it? |
Smaller images have fewer packages and so usually fewer findings, but they can be harder to debug. Many teams use a minimal image for production and a separate debug variant for troubleshooting.
A step by step approach
- List what the service needs at runtime. Language runtime, native libraries, certificates, time zone data.
- Start from the smallest image that supplies those. Use a multi stage build so build tools stay out of the final image.
- Pin the image by digest, not a floating tag, so builds are repeatable.
- Run as a non root user. Drop capabilities your service does not need.
- Scan the image in CI and block builds that add high risk findings.
- Rebuild on a schedule even without code changes, so base image updates arrive.
- Record the image's SBOM with the release.
Mistakes to avoid
- Copying the monolith's Dockerfile unchanged
- Using a floating tag such as latest, which changes without notice
- Leaving build tools and test dependencies in the runtime image
- Never rebuilding, so the image ages in place
- Ignoring the application layer. Image scanning covers the operating system packages and, depending on the tool, application libraries too. Make sure both are included.
How it ties to the monolith baseline
Compare the new service's image findings to the monolith baseline. A good extraction should show a short list of packages and findings. If the list is long, check what came along that the service does not use.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are grouped by layer, so you can tell whether they come from the base image or from your own dependencies.
Safeguard's container image scanning and SBOM generation can support these checks, and its policies can gate builds. See also how to set up mutual TLS between microservices for service to service concerns.
Quick check
Why pin by digest?
A tag can point to different content over time. A digest identifies exact content, so builds are repeatable.
Do I still need to rebuild if my code did not change?
Yes. Base image updates only reach you when you rebuild.
Last reviewed: 19 October 2026.
