Reducing container footprint to lower attack surface creates a troubling tradeoff: security scanners lose visibility into what actually runs inside. The industry faces mounting pressure to balance minimal images against the scanning clarity needed for production deployments.

The anatomy of container bloat

Standard container workflows historically relied on pulling complete operating system base images, layering application code on top, and shipping to production. While straightforward, this approach introduced substantial risk. Full images carried shells, package managers, and numerous utilities the running application never touched. Each unused component represented potential vulnerability surface and a toolkit available to attackers if the application itself was compromised.

The distroless security gap

The distroless movement responded by stripping containers to only bare-minimum runtime dependencies—no shell, no package manager, no extra tools. This reduced attack surface but introduced operational complexity. Building distroless images proved fragile and error-prone, and the aggressive trimming process often removed package metadata entirely.

The consequence is what the industry now calls the "distroless security gap." Vulnerability scanners like Trivy flag warnings when OS package metadata is absent. A 2022 Rezilion report by Yotam Perkal documented that container scanners produce significant false negatives, failing to detect active vulnerabilities due to missing context. Organizations including Chainguard have noted that incomplete package metadata prevents scanners from accurately reflecting image contents.

You might have built an incredibly small container, but if your security team can't scan it and mathematically prove it is safe, it becomes a massive compliance liability.

Organizations face an imperfect choice: bloated containers with large attack surfaces, or minimal containers that resist auditing.

Face-off: Imperative trimming vs bottom-up assembly

A third approach exists. Rather than starting with a large image and trimming downward—risking loss of metadata needed for accurate scanning—containers can be built from the bottom up. This method constructs minimal images from scratch, including only required elements. Because assembly proceeds upward rather than through removal, metadata stays intact. The open source ecosystem calls this generation of minimal, auditable OCI images "rocks."

Bottom-up container builds follow three distinct stages: Slice, Build, and Run.

Station 1: Precision slicing

The process begins with an empty image. Using open-source tools like Chisel, developers slice standard, trusted Linux packages from sources such as Ubuntu archives into smaller, granular pieces. Rather than pulling entire packages, only the specific "slices" the application requires get selected. Since these slices originate from curated archives, a trusted software supply chain is maintained with surgical precision. Critically, slice metadata remains preserved, keeping security scanners fully functional.

Station 2: Declarative builds

Diagram illustrating the precision slicing capability of a bottom-up build.
Click to enlarge graphic.

Traditional container assembly uses imperative Dockerfiles where command order matters and layer caching creates fragility and bloat. Bottom-up builds employ a declarative model instead. Using open-source build tools like Rockcraft, developers write a simple YAML file describing the application and its requirements. The tool fetches source code, pulls requested package slices, compiles everything, and outputs a standard OCI-compliant image.

It shifts the developer experience from 'scripting a build' to 'declaring a state.'

name: chiseled-python
base: bare

build-base: ubuntu@26.04-lts
version: "3.14"
summary: Chiseled Python3.14 rock
description: Chiseled Python rock
license: Python-2.0
platforms: { amd64: }

run-user: _daemon_

parts:
    install-python:
        plugin: nil
        stage-packages:
          - base-files_release-info
          - python3_core

Station 3: Taming PID 1 at runtime

Minimal containers face a final operational challenge at runtime. Standard operating systems manage processes automatically, but containers running applications that spawn child processes encounter "zombies"—dead processes consuming system resources. Without a proper init system, zombies accumulate until container failure causes cascading outages at scale. Traditional base images include process managers; distroless images often omit them to save space. Bottom-up containers address this using lightweight service managers like Pebble, which runs as PID 1, serves as the container entry point, and safely reaps zombie processes without reintroducing bloat.

What's next

The cloud-native ecosystem has long treated security visibility and container minimalism as mutually exclusive. The distroless movement highlighted bloated image dangers but created unacceptable scanning blind spots for enterprise production. Shifting from imperative, top-down trimming to declarative, bottom-up assembly lets engineering teams achieve both objectives. Security-maintained, minimal containers become auditable and operationally stable. Container security no longer requires sacrificing developer experience or Day 2 visibility.