Distroless images blind your vulnerability scanners: bottom-up containers restore the visibility
On October 19, 2026, a CNCF post detailed the distroless paradox: stripping out the shell and package manager also erases the metadata scanners need, producing false negatives. If your minimal image cannot be audited by Trivy, rebuild it from the bottom up to keep the metadata without reintroducing the bloat.
October 19, 2026. A post published on The New Stack under the CNCF banner describes the “distroless security gap.” 2022. The Rezilion report by Yotam Perkal was already documenting container-scanner false negatives. Trivy. The scanner that raises warnings when OS package metadata is missing. Why it matters: shrinking an image shrinks the attack surface, but if the scanner can no longer prove what the image contains, it becomes a compliance liability.
The anatomy of container bloat
For a long time, the full image was the standard. The developer pulled a base image carrying an entire operating system, stacked application code on top, and shipped it to production. It was convenient, and it was a massive security problem.
Those images bundled a shell, a package manager, and dozens of utilities the application never used at runtime. Every unused piece of software was a potential vulnerability and an unnecessarily wide attack surface. If an attacker breached the application, they suddenly had a full toolkit to download more utilities and escalate the attack.
The distroless security gap
The distroless movement emerged to answer this. The idea was sound: strip the container down to the bare dependencies the application needs to run. No shell, no package manager, no extra utilities.
The attack surface did shrink, but at a steep operational cost. Building a distroless image is complex, fragile, and error-prone. In the effort to cherry-pick and aggressively trim, the package metadata — the manifest of what is actually installed — often gets stripped out completely.
The unintended consequence has a name: the “distroless security gap.” It is not theoretical. Trivy raises explicit warnings when OS package metadata is absent, and the 2022 Rezilion report showed scanners suffering from significant false negatives — failing to detect active vulnerabilities for lack of context. Chainguard made the same observation: if a scanner cannot collect complete package metadata, the result does not reflect the image’s true contents.
Between full and distroless images, the choice becomes imperfect: bloated containers with a wide attack surface, or minimal containers you cannot audit.
Three stations: Slice, Build, Run
There is a third way. Instead of starting from a large image and trimming it down, you build the container from the bottom up, including only the exact elements you need. Because you assemble rather than strip, the metadata stays intact. In the open-source ecosystem, this generation of minimal, auditable OCI images is sometimes called “rocks.”
The build runs like a conveyor belt with three stations.
Station 1 — precision slicing. The container starts literally empty. With a tool like Chisel, you slice trusted Linux packages — for example from the Ubuntu archives — into granular pieces. You pull only the exact “slices” your application needs, not the whole package. Because the slices come from curated archives, you keep a trusted supply chain, and their metadata remains available to the scanner.
Station 2 — declarative builds. Historically, containers are assembled with imperative Dockerfiles, where the order of commands matters and layer caching creates bloat and fragility. Bottom-up builds replace that with declarative tooling: with a tool like Rockcraft, the developer writes a YAML file describing the application and its needs. The tool fetches the source, pulls the requested slices, compiles, and outputs a standard OCI image. The experience shifts from “scripting a build” to “declaring a state.”
name: chiseled-python
base: bare
build-base: [email protected]
version: "3.14"
parts:
install-python:
plugin: nil
stage-packages:
- base-files_release-info
- python3_coreStation 3 — taming PID 1 at runtime. The last difficulty of minimal containers is process management. In a normal operating system, the OS handles it. In a container, if the application spawns child processes that die, they leave zombies that pile up until the container crashes. Traditional images bundle a process manager; distroless ones often strip it out. To stay stable without reintroducing bloat, bottom-up containers use a tiny service manager like Pebble, which runs as PID 1 and reaps zombies.
What to verify before adopting
The CNCF post is authored by a Canonical product manager, and the three tools it cites — Chisel, Rockcraft, Pebble — are that vendor’s projects. It is as much a demonstration as an analysis. The core thesis still holds independently of the vendor: the problem is not minimalism, it is the loss of metadata that travels with it.
Other routes reach the same destination. Chainguard assembles its Wolfi images with apko, preserving APK metadata. Google’s distroless images remain a standard for static runtimes. Alpine keeps a minimal but usable package manager. The underlying question is the same everywhere: can your scanner enumerate what the image contains, and does that enumeration match the actual contents?
How to check your image
The test is quick to run. On a minimal image, Trivy signals missing metadata with an explicit warning; on a full image, it enumerates a long list of packages most of which never run. The right question is not “is the image small?” but “does the manifest match the contents?”.
trivy image --scanners vuln my-image:tag 2>&1 | grep -i "metadata\|package"If the scanner returns an empty package list while the image ships a Python or Node runtime, that is the symptom of the visibility gap: the image may be safe, but nothing proves it.
Runtime stability is verified the same way. A container without a PID 1 manager that spawns child processes — a web server that forks, an orchestrator that runs jobs — ends up accumulating zombies. The symptom is mundane: defunct processes piling up in ps, memory creeping up, then a crash nobody links back to the image. Pebble, or any minimal init, reaps those processes and makes the behavior deterministic.
On compliance, the pressure comes from regulation. The European Cyber Resilience Act and audits like SOC 2 or ISO 27001 require you to enumerate a system’s software components. A minimal image that resists scanning turns a documentation requirement into an audit failure — not because the image is vulnerable, but because you cannot prove it is not.
In practice, this visibility materializes as an SBOM (Software Bill of Materials) that the scanner can cross-reference against vulnerability databases. A bottom-up image produces that SBOM natively, because every slice is traced from the source archive through to runtime — where a hand-trimmed image loses it along the way. The operational payoff is not abstract: when a CVE drops, the team that can enumerate its images patches in hours; the team that cannot spends days guessing what it runs.
The shift is also cultural. Imperative Dockerfiles reward the engineer who knows the exact sequence of commands; declarative builds reward the engineer who can state what the image should contain and let the tool prove it matches. For organizations moving fast with AI-assisted builds, the second skill scales better.
Verdict
If your minimal image raises Trivy warnings about missing metadata, treat that as a blocker, not noise: an image you cannot scan is a compliance debt that will come due at audit time. If you build production images for interpreted runtimes, try a bottom-up build — Chisel and Rockcraft on the Ubuntu side, apko on the Chainguard side — to keep visibility without reintroducing a shell. If you manage a heterogeneous fleet, enforce one simple rule: every image must be auditable by your scanner, or it does not reach production.