Often, but not always. Fewer packages usually means fewer places for a known flaw to hide, so a trimmed image tends to produce fewer findings. Size alone is a rough proxy, though. A small image can still ship a vulnerable library, and a large one can be well patched.
Myth versus fact
| Statement | Verdict |
|---|---|
| Smaller image always has fewer vulnerabilities | Myth |
| Removing tools you do not run reduces what can be flagged or abused | Fact |
| Image size and patch level are the same thing | Myth |
| Multi-stage builds keep build tools out of the final image | Fact |
| A clean scan on a small image proves it is safe | Myth |
Why size is only a proxy
Size counts bytes, and bytes include data files, language runtimes, assets and compressed layers. Vulnerabilities live in specific package versions. A 50 megabyte image with one old library that has a serious flaw is worse than a 300 megabyte image whose packages were rebuilt yesterday.
Docker's multi-stage documentation says that none of the build tools required to build the application are included in the resulting image. That is a real reduction in installed software, and it is the main honest argument for small images: fewer components, fewer shells and utilities for an attacker to reuse after a break in.
What to measure instead
- Package count and the number of known findings by severity.
- Age of the base image and the last rebuild date.
- Whether the OS release is still supported. See checking base image end of life.
- Whether the findings affect code your app actually loads. Reachability analysis helps here, because a flaw in a package that is installed but never called is lower priority than one on the request path.
- Whether the image runs as a non-root user.
A simple experiment
Build the same app on two bases, one full and one slim. Scan both and compare the number of packages, the number of findings, and the findings that are relevant. Then rebuild both with a fresh pull and compare again. You will often see that rebuilding moves the numbers as much as switching base.
Tradeoffs of going small
Minimal images may lack a shell and common utilities, which makes debugging harder, and some may use a different C library that changes behavior for certain binaries. Test the app thoroughly and plan how you will debug, for example with a separate debug stage. See build targets for debug and production.
A reasonable policy
Prefer the smallest base your app runs well on, build in stages, keep the image rebuilt, and measure findings, not megabytes.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is distroless always the safest choice?
It removes a lot of software, but you still need to patch what remains and check how you will debug. Judge by findings and maintenance, not by label.
Do I still need to scan a minimal image?
Yes. Your application dependencies are inside it, and they are usually where findings come from.
Safeguard
Safeguard does SBOM and dependency scanning, and its policies and gates can run in CI so a bad image does not reach production. You can try a free scan before deciding anything.
Sources
Last reviewed: 19 October 2026.
