Distroless Images Shrink the Attack Surface — Not the CVE List

Strip the shell. Drop the package manager. Cut the image to a few megabytes of pure runtime. An attacker who gets code execution can't open a bash prompt, can't apt install their way to fresh tooling, and loses most of their "living off the land" tricks. Distroless feels like a finished job.

It is not the finished job. It is the start of a different one.

The numbers behind the boom

Safeguard's research team scanned more than 4.2 million publicly indexed images from January through June 2026. Their headline: distroless and other minimal-base images now make up about 23% of newly published images on major registries — up from roughly 9% at the start of 2024.

The shift is lopsided. Go and Rust services lead the way, with distroless or scratch final stages in 41% of freshly built Go service images in Q2 2026. Python trails at 12%, Node.js at 8% — native dependency chains make it harder to strip them down.

The attraction is real, and the hardening is real. Smaller surface, no interactive shell, fewer binaries to weaponize.

The part nobody mentions

Here is where the comfortable story cracks. Across the distroless images Safeguard analyzed, the median image still shipped 47 identifiable open-source packages at the application layer. Sixty-one percent of those images contained at least one package with a known High or Critical CVE on NVD severity.

Removing the shell did not remove the vulnerable JSON parser, the stale TLS library, or the deserialization bug hiding in a logging framework. Distroless changes the exploitation path, not the underlying vulnerability inventory.

Worse, it can actively hide that inventory. Most vulnerability scanners lean on package-manager metadata — the /var/lib/dpkg files and friends that a trimmed image simply doesn't have. Run Trivy against a distroless image and you may see a warning right out of the box: "No OS package is detected. Make sure you haven't deleted any files that contain information about the installed packages." Safeguard found that OS-metadata-dependent scanners missed an average of 18% of the components still sitting inside the image as statically linked libraries and vendored code.

So your CVE count is quietly underreporting. And at the same time — here's the second twist — the count it does report is overinflated. When Safeguard ran reachability analysis on the findings, only 22% of the Critical and High items involved a function an application could actually reach. The other 78% were present in the dependency tree but structurally inert. Your scary scan is partly noise; your clean scan is partly a lie.

What a team should actually do

Keep the distroless decision. It is a good attack-surface reduction. But stop calling it "fewer vulnerabilities," because that is not what it does.

• Generate SBOMs from binary composition, not package metadata. If your scanner can't read the inventory, build it from the binary. Compliance regimes (US Executive Order 14028, the EU Cyber Resilience Act) want an accurate per-artifact inventory, and metadata-free images are where audits quietly fail.
• Triage with reachability. Filter the list for functions your app can actually call, so the 22% that matters survives and the 78% of noise falls away.
• Obsess over patch cadence, not starting CVE count. Aqua counted roughly 28,000 new CVEs disclosed during 2024. A base rebuilt nightly after an upstream fix (Chainguard's Wolfi project does this) beats a pristine-but-static image every time.

Distroless was never the finish line. It bought you a cleaner attack surface — now you have to actually look at what's inside.