Pick a base container image from a source you can verify, make it as small as your application allows, pin it by digest so builds are repeatable, and rebuild it on a schedule so patches flow in. Use a larger image to build and a slim one to run. This is a decision guide, not a ranking of images.
Why does the base image matter so much?
Everything in the base image ships with your application. NIST SP 800-190, the Application Container Security Guide, explains that images are static archives: components may be outdated or missing security updates, and an image that is clean when built will, at some point, contain a known vulnerability. Unlike traditional servers, updates are made upstream in the image and then redeployed, so a common container risk is simply running an image that was never rebuilt.
The guide names other image risks that begin at the base: configuration defects such as running as a privileged user or including an SSH daemon, embedded malware (it points to base layers from third parties of unknown provenance as one source), clear-text secrets baked into the image, and the use of untrusted images.
What should you look for in a source?
Container documentation advises building from a trusted source and keeping the image small. It describes curated, regularly updated official images, and images from verified publishers whose content a registry operator has authenticated, with badges that show membership. NIST adds the principle: running untrusted software is one of the most common high-risk scenarios, and the ease of pulling an image from a forum answer reintroduces the same risks as any external software, including malware, data leakage and vulnerable components.
So the first questions are: who publishes it, how often is it rebuilt, is the Dockerfile or build recipe visible, and does the publisher state a support period?
How small is small enough?
The Docker build documentation says a smaller base gives portability and fast downloads, shrinks your image and reduces the number of vulnerabilities introduced through dependencies. It suggests two types of base image: one for building and unit testing, and a typically slimmer one for production, since a running service rarely needs compilers, build systems or debugging tools. Multi-stage builds do this in one Dockerfile by copying only the needed output into the final stage.
Smaller is not free. A minimal image may lack a shell or package manager, which makes debugging harder and some libraries impossible to install. Pick the smallest image that runs your application's actual dependencies, and test it.
Why pin by digest?
Tags are mutable. The Docker documentation shows that a tag like alpine 3.21 may point to one patch version today and another in three months. That is useful for getting fixes, but it means builds are not repeatable and you have no audit trail of the exact image used. Pinning to a digest guarantees the same image even if the publisher moves the tag. The documentation says this is how you fully secure supply chain integrity, and it pairs it with regular rebuilds so a pinned digest does not go stale.
Docker also notes the flag for pulling a fresh base image during a build, and a separate flag to bypass the build cache so dependencies from package managers are refreshed. They do different things and can be combined.
A constructed example
A team has a Python service on a full general-purpose base image with hundreds of packages. A scan reports 140 findings, most in packages the service never uses, such as a mail agent and a text editor. They move to a slim base for runtime, using a fuller image only in the build stage. Findings fall to a handful, and the image runs as a non-root user. They pin the digest and set a weekly rebuild that opens a pull request with the new digest and a scan report. When a high-severity flaw lands in the language runtime, the rebuild picks up the fix within days instead of whenever someone remembers.
How to check or apply this
- List candidate images and check publisher, rebuild frequency, support period and whether the build recipe is public.
- Choose the smallest image that runs your dependencies. Test startup, debugging and any native libraries.
- Use multi-stage builds: a full image to compile, a slim one to run.
- Run as a non-root user and do not bake secrets into the image.
- Pin the base by digest and automate updates through a reviewed pull request.
- Scan every build at every layer. NIST asks for tools that cover the whole image lifecycle, see all layers including application frameworks, and support policy gates that stop images above a chosen CVSS threshold from progressing.
Safeguard's dependency and SBOM scanning shows what is inside your application layers, reachability analysis ranks which findings your code actually calls, and policies and gates can block a build that breaks your rules.
Quick check
Is the latest tag a safe choice for a base image?
No. Mutable tags change over time and make builds unrepeatable. Pin to a specific version and digest, and update deliberately.
Does a smaller base image always mean fewer vulnerabilities?
Usually, because fewer packages mean fewer places for flaws. Still, scan the result, because the application layers you add can bring their own.
Sources
- NIST SP 800-190, Application Container Security Guide, sections 3.1 and 4.1
- Docker documentation, guidance on building images, choosing and pinning base images
Last reviewed: 18 October 2026.
