Container Base Images — Trivia & Interesting Facts¶

Surprising, historical, and little-known facts about container base images.

Alpine Linux was not built for containers¶

Alpine Linux was originally created in 2005 by Natanael Copa as a fork of LEAF (Linux Embedded Appliance Firewall), designed for routers and firewalls. Its adoption as the go-to minimal container base image was an accident of timing — Docker popularized it around 2015 because its 5 MB footprint made layer pulls dramatically faster than the 200+ MB Ubuntu images everyone else was using.

The scratch base image is literally nothing¶

Docker's scratch base image contains zero bytes — no filesystem, no shell, no libc, nothing. It was introduced so that statically compiled Go binaries could run in containers with absolutely no OS layer. A "Hello World" Go container built FROM scratch can be under 2 MB, compared to 70+ MB on Ubuntu.

musl vs glibc has crashed more production containers than most people realize¶

Alpine uses musl libc instead of glibc. This seemingly minor difference has caused countless subtle production failures: DNS resolution behaving differently under load, Python packages segfaulting, Java applications hanging on thread creation, and Node.js binaries refusing to start. The musl DNS resolver notably does not support the search directive in resolv.conf the same way, which broke Kubernetes service discovery for many teams before workarounds were documented.

Distroless images were Google's answer to the CVE treadmill¶

Google created "distroless" images in 2017 after getting tired of patching CVEs in packages their applications never used. By stripping everything except the language runtime and ca-certificates, they reduced the CVE surface by over 90% in some cases. The images do not contain a shell, which means you cannot docker exec into them — this is considered a feature, not a bug.

The Ubuntu base image shrank by 60% and nobody noticed¶

In 2018, Canonical released "chiseled" Ubuntu images inspired by distroless, cutting the base from ~73 MB to ~29 MB. They achieved this with a tool that extracts only the specific files (down to individual shared libraries) needed by an application. The .NET team at Microsoft was one of the first major adopters, publishing official chiseled .NET images.

Red Hat's UBI changed the licensing game¶

Before Red Hat Universal Base Images (UBI) launched in 2019, using RHEL-based container images required a subscription. UBI made a subset of RHEL packages freely redistributable, letting anyone build on a RHEL foundation and deploy anywhere. This was a major strategic shift — Red Hat essentially gave away the base to sell the platform (OpenShift).

Wolfi is a Linux "undistro" built specifically for containers¶

Chainguard created Wolfi in 2022 as the first Linux distribution designed from the ground up exclusively for containers. It has no kernel (containers share the host kernel), uses apk like Alpine but links against glibc instead of musl, and every package includes SBOM metadata and is built with full provenance attestations. The name comes from the world's smallest octopus, Octopus wolfi.

The busybox base image packs 400 Unix utilities into 1 MB¶

BusyBox, often called the "Swiss Army knife of embedded Linux," compiles approximately 400 common Unix utilities (ls, grep, awk, sed, vi, wget, etc.) into a single static binary under 1 MB. The container image based on it gives you a functional shell environment at a fraction of the cost of any traditional distribution.

Debian slim images remove documentation to save space¶

Debian's -slim variants are not rebuilt from scratch — they are the full Debian images with /usr/share/doc, /usr/share/man, locale files, and other non-essential content deleted. This simple cleanup saves about 50 MB, roughly a 40% reduction. The technique is so effective that many teams apply the same pattern to their own custom images via .dockerignore and multi-stage builds.

Base image tag "latest" has caused mass outages¶

The latest tag is not a version — it is a mutable pointer that changes whenever a new image is pushed. Companies including Knight Capital (in a related pattern) and several documented incidents on public postmortem trackers have traced production outages to a base image latest tag silently pulling a new major version with breaking changes. This is why every container security guide insists on pinning by digest (sha256).

The average container base image contains 70+ known CVEs¶

A 2023 Sysdig report found that the average container image in production contained over 70 known vulnerabilities. However, roughly 87% of high/critical CVEs were in packages that were never loaded at runtime. This gap between "installed" and "used" drove the entire industry toward minimal base images and runtime-aware vulnerability prioritization.

Chainguard reduced CVE counts to zero — and proved it is possible¶

Chainguard Images launched with a bold claim: zero known CVEs at time of build. They achieved this by rebuilding every package from source daily, aggressively patching, and stripping unused packages. Independent scans by Snyk and Trivy confirmed the claim for their base images, demonstrating that the "CVEs are inevitable" assumption was actually a build-process problem, not a fundamental constraint.

Image Optimization Trivia¶

Multi-stage builds were Docker's most requested feature for three years¶

Multi-stage builds were proposed in 2014 and shipped in Docker 17.05 (May 2017). Before multi-stage, people used shell scripts to chain multiple docker build commands, copying files between containers manually. The feature reduced image sizes by 10-50x for compiled languages.

The dive tool revealed that most images are 40-60% waste¶

When wagoodman released dive in 2018, teams were shocked to discover that their images contained massive amounts of wasted space. Common findings: package manager caches, build tools, documentation, locale data, and files added in one layer and deleted in a later layer (still present in the earlier layer).

Nydus and eStargz let containers start before the image is fully downloaded¶

Traditional image pull downloads all layers before starting the container. Nydus (CNCF) and eStargz (Google/AWS) enable lazy-pulling: the container starts immediately and fetches layers on-demand as files are accessed. This reduces cold-start times from minutes to seconds for large images.

Image Scanning Trivia¶

Trivy started as a weekend project and became the industry standard¶

Teppei Fukuda created Trivy as a side project in 2019. Aqua Security hired him and made Trivy their official open-source scanner. By 2023, Trivy was the default scanner in Amazon ECR, Harbor, GitLab, and dozens of CI platforms. Its success came from simplicity: trivy image myapp:latest just works.

A 2022 study found that 87% of critical CVEs in containers were never loaded at runtime¶

Sysdig's 2023 Cloud Native Security Report found that the vast majority of high/critical CVEs exist in packages that are installed but never executed. This drove the industry toward runtime-aware scanning and VEX documents for communicating exploitability context.

Scanners disagree with each other more than people expect¶

Running Trivy, Grype, and Snyk on the same image often produces different results. Differences arise from: which CVE databases they consult, how they handle vendor-specific advisories (Debian, Alpine, Red Hat each assess CVEs independently), and how they match package names. Running multiple scanners is recommended for high-security environments.

CVE-2021-44228 (Log4Shell) was in a Java library nested inside a shaded JAR. Most scanners at the time could detect OS packages and top-level language dependencies, but not libraries embedded inside archives. This drove rapid improvement in "deep scanning" capabilities across all major scanners.