Container images stripped down to reduce their attack surface are now blinding vulnerability scanners to what's actually inside them, according to a new analysis published by The New Stack. The analysis identifies what it calls the "distroless security gap"—an industry-wide problem where efforts to minimize containers often remove the package metadata that security tools need to detect vulnerabilities. Organizations are caught between two bad options: bloated containers with large attack surfaces, or minimal containers they can't properly audit.
The problem stems from how distroless images are created. When developers aggressively trim a container image to include only the bare-minimum dependencies needed for an application to run—removing shells, package managers, and extra utilities—the package metadata that lists what's installed often gets stripped out entirely. Scanners like Trivy throw warning flags when operating system package metadata is missing, and a 2022 Rezilion vulnerability report revealed that container scanners suffer from significant false negatives, failing to detect active vulnerabilities simply because they lack the necessary context. Organizations including Chainguard have noted that when a scanner can't collect complete package metadata, the scan results won't accurately reflect the image's true contents.
The analysis argues that an incredibly small container becomes a massive compliance liability if a security team can't scan it and mathematically prove it is safe. Traditional full container images included complete operating systems with shells, package managers, and countless tools the application never used at runtime—every piece of unused software represented a potential vulnerability. The distroless movement emerged to address this by stripping containers to their essentials, which certainly reduced the attack surface but came at a steep operational cost: creating distroless images is complex, fragile, and error-prone.
The solution proposed involves building containers from the ground up rather than trimming them down. Instead of taking a large image and removing components—risking the loss of crucial metadata needed for accurate security scans—a bottom-up approach starts with an empty image and adds only the exact elements required. Using open-source tools like Chisel, developers slice standard Linux packages into smaller pieces and include only the precise slices their application needs. Because these slices come straight from curated archives, the metadata is preserved and security scanners stay fully operational. A declarative build tool like Rockcraft replaces traditional imperative Dockerfiles with a simple YAML file that describes the application and its needs, shifting the developer experience from scripting a build to declaring a state. At runtime, lightweight service managers like Pebble handle process management to prevent zombie processes from piling up and crashing containers at scale.
The analysis concludes that the cloud-native ecosystem has treated security visibility and container minimalism as a zero-sum game for too long. By shifting from an imperative, top-down trimming approach to a declarative, bottom-up assembly process, engineering teams can achieve both security-maintained minimal containers that are auditable and operationally stable. Container security shouldn't come at the expense of developer experience or Day 2 visibility. The infrastructure choices made today will determine whether security teams can maintain visibility as containers continue to proliferate across enterprise environments. Organizations that wait for the industry to resolve this tension may find themselves forced into reactive compliance postures rather than proactive security strategies.