Bottom‑up containers close the distroless security gap

Container image construction has shifted from starting with a complete OS and stripping it down, to building images from an empty base and adding only the exact pieces an application needs. Practitioners care because the new approach retains the auditability required by vulnerability scanners while still delivering the minimal footprint that security teams demand.

Why the shift matters

Traditional images bundled a full operating system, a shell, a package manager, and many utilities that never run in production. Each unused component expanded the attack surface and gave an attacker a ready‑made toolkit. The distroless movement removed most of those components, but in doing so it also stripped the package metadata that scanners rely on. Tools such as Trivy raise warnings when that metadata is missing, and reports from Rezilion (2022) and observations from Chainguard note a rise in false‑negative findings, turning a small image into a compliance liability.

Bottom‑up build workflow

A bottom‑up approach, sometimes called a “rock”, reverses the trim‑first mindset. It consists of three logical stations:

• Slice: Starting from an empty image, an open‑source tool like Chisel extracts only the required files from trusted Linux package archives (e.g., Ubuntu). The slices retain their original package metadata, keeping the image transparent to scanners.
• Build: Instead of an imperative Dockerfile, developers write a declarative rockcraft.yaml that lists the needed slices and build parameters. The Rockcraft tool resolves the slices, compiles the application, and emits a standards‑compliant OCI image.
• Run: Minimal images still need a reliable PID 1 process. Practitioners must ensure the runtime includes an appropriate init strategy to handle child processes and signal propagation.

Operational and security implications

Preserving package metadata means existing scanning pipelines (e.g., Trivy) can continue to provide full coverage without false negatives. The declarative build model reduces layer churn and makes reproducibility easier, which benefits CI/CD stability. However, teams must adopt the new tooling chain (Chisel, Rockcraft) and verify that their supply chain policies accept sliced packages from upstream archives.

Process management inside the container becomes a more explicit concern. Since the image lacks a traditional init system, operators should either embed a lightweight init binary or configure the entrypoint to handle signal forwarding, otherwise child processes may become orphaned.

Related CloudNinjas coverage: hands-on guides.

What This Means For Practitioners

• Evaluate whether your current scanning tools can ingest the metadata produced by sliced packages; if not, plan a pilot with a bottom‑up image.
• Introduce Rockcraft into your build pipeline to replace imperative Dockerfiles where auditability is critical.
• Confirm that your CI/CD system can source packages from the same trusted archives used by Chisel to avoid supply‑chain drift.
• Implement a robust PID 1 strategy—either a minimal init binary or a well‑tested entrypoint script—to ensure runtime stability.