Yes, but a scanner finds different evidence in each. Distroless images usually still carry operating system package records, so they scan like any other image with fewer rows. A scratch image holds only what you copied in, so results depend on whether your binary embeds its dependency list. Check coverage, not just the count.
What these images are
The Docker documentation describes FROM scratch as a special base for minimal images containing only just what an application needs. Nothing else is inside: no shell, no package manager, no operating system files unless you copy them.
The distroless project describes its images as containing only your application and its runtime dependencies, without package managers, shells or other programs you would expect in a distribution. Its README says this improves the signal to noise of scanners, because there is less software to report on.
Where scanners look for components
| Image type | Typical evidence | Risk of missed components |
|---|---|---|
| Full distro base | Package database, language manifests | Low |
| Distroless | Reduced package records, language files | Low to medium |
| Scratch with static binary | Metadata inside the binary, if present | Higher |
| Scratch with only config files | Nothing to match | Not applicable |
Scanners identify operating system packages from the package manager's records in the image. When those records are removed or never existed, there is nothing to read, and a clean result can mean "nothing found" rather than "nothing vulnerable".
The Go case
Go is the common scratch example. A Go binary built with module support embeds build information. The Go runtime documentation says ReadBuildInfo returns the build information embedded in the running binary, and that the information is available only in binaries built with module support. A scanner that reads that data can list the modules compiled in.
Practical consequences:
- Build with modules and avoid stripping that information if you want scanners to see it.
- Know that a binary built without that data will scan as empty.
- Prefer generating the SBOM from the source or from the build, where your lockfile exists, and attach it to the image. See scanning a built binary versus source for the same issue in Java.
Other languages differ. A statically linked C program has no embedded dependency list at all, so only build-time records can describe it.
How to check your coverage
- Take an image you know well and list what you expect: runtime, libraries, certificates.
- Run the scan and compare the components it reports.
- If components are missing, generate an SBOM at build time and compare again.
- Record the gap as a known limit of image scanning for that image type.
Pair image scanning with source-level dependency scanning, so the lockfile covers what the binary hides. See multi-stage builds and attack surface.
Do small images have fewer vulnerabilities
Usually fewer findings, and often fewer real exposures. But a smaller number can also come from a scanner that sees less. Treat the count and the coverage as two separate numbers. We cover the first question in does a smaller container image mean fewer vulnerabilities.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for how the demo separates operating system packages from application packages.
Where Safeguard fits
Safeguard combines image scanning with dependency scanning and SBOM generation, so the lockfile can fill gaps the image hides. Try the free scan on a minimal image and compare it with your expectations.
Quick check
Is a scratch image with a clean scan safe?
Not automatically. Confirm the scanner could see the components in your binary. If it could not, rely on the build-time SBOM and dependency scan.
Do distroless images need scanning at all?
Yes. They still contain runtime libraries and your application dependencies, both of which can have advisories.
Sources
Last reviewed: 19 October 2026.
