Alpine and distroless are the two most common answers to "how do I shrink my container attack surface," and they solve the problem in almost opposite ways. Alpine Linux (built on musl libc, busybox, and the apk package manager) ships a full, if minimal, Linux distribution in roughly 7 MB. Distroless, maintained by Google since 2017, strips even further: no shell, no package manager, no coreutils — just glibc, your app, and its runtime dependencies. Both routinely get recommended as "the secure base image" in the same breath, which isn't quite right. Alpine's musl libc has shipped its own CVEs (CVE-2019-5021, CVE-2021-30139, CVE-2020-28928), while distroless's missing shell eliminates a whole class of post-exploitation techniques but doesn't reduce your library CVE count. Below is what the actual track record shows, image by image.
What's actually different between Alpine and distroless?
The core difference is that Alpine is a complete, minimal distribution and distroless is a deliberately incomplete one. Alpine ships musl libc, busybox (which alone provides over 200 stripped-down Unix utilities), and the apk package manager, all inside an image that's typically 5–7 MB (alpine:3.19 is 7.34 MB compressed). Distroless, by contrast, is built from Debian package contents but the runtime images (gcr.io/distroless/base-debian12, gcr.io/distroless/static, gcr.io/distroless/java17, etc.) deliberately exclude a shell binary, apt/dpkg, and most of coreutils. distroless/static is around 2 MB; distroless/base-debian12, which includes glibc and libssl for dynamically linked binaries, is around 20 MB. Alpine gives you a real (tiny) OS you can apk add into and shell into for debugging. Distroless gives you almost nothing to attack even if a container escape succeeds — there's no /bin/sh for an attacker to pivot into.
Does a smaller image mean fewer vulnerabilities?
No — image size and CVE count are only loosely related, because most CVEs come from application-layer dependencies, not the base OS. A 20 MB distroless/base-debian12 image still bundles glibc, libssl, and ca-certificates, each of which has its own CVE history (glibc alone has had double-digit CVEs across 2022–2024, including CVE-2023-4911, the "Looney Tunables" buffer overflow in ld.so). Alpine's 7 MB footprint means fewer total packages (typically 15–20 versus distroless's 4–8, but distroless's packages are heavier libraries), so there are fewer places for a base-layer CVE to hide — but your Node.js, Python, or Java dependencies sitting on top will dwarf either OS's CVE count in a typical scan. Size reduction narrows the attack surface for OS-level exploits and living-off-the-land binaries; it does not substitute for scanning what your application actually pulls in.
Which base image has a better historical CVE track record?
Distroless has fewer base-layer CVEs on record, but Alpine's most serious incident was worse in impact than anything distroless has had. The clearest data point against Alpine is CVE-2019-5021 (CVSS 9.8): Alpine Docker images from version 3.3.0 through 3.9.2, going back to 2015, shipped with a blank root password in /etc/shadow, meaning any process that could reach a login prompt (or that inherited a shell) could authenticate as root with no credentials. It was disclosed on March 1, 2019, and fixed in Alpine 3.9.3. That vulnerability class is structurally impossible in distroless, because there's no login mechanism or shell to exploit in the first place. On the flip side, Alpine's apk-tools had CVE-2021-30139, a TLS certificate verification bypass in apk versions before 2.10.6 and 2.12.1, patched in March 2021 — a bug that doesn't apply to distroless at all since it has no package manager to patch post-build.
Does Alpine's musl libc introduce risks glibc doesn't have?
Yes, musl's smaller, non-POSIX-complete implementation has caused both security and reliability bugs that glibc-based distroless doesn't share. CVE-2020-28928 is a buffer overflow in musl's wcsnrtombs() function, present in musl 1.1.24 and earlier, disclosed in November 2020 and fixed in the musl 1.2.0 line. Beyond CVEs, musl's stub resolver historically lacked TCP fallback for DNS responses over 512 bytes, a gap documented across Kubernetes and Go community threads since 2017–2018 that caused intermittent DNS resolution failures for Alpine-based pods — not a CVE, but a correctness gap that has pushed some teams away from Alpine for production services with heavy DNS lookups (large service meshes, multi-record SRV lookups). glibc, used in distroless's base variants, has a much larger and more heavily fuzzed codebase, but that size cuts both ways: CVE-2023-4911 ("Looney Tunables") affected glibc's dynamic loader across nearly every major Linux distribution using glibc versions from 2.34 onward, including distroless base images that link against it.
Which is easier to scan and patch at scale?
Alpine is easier to patch in place; distroless is easier to scan reliably. Because Alpine keeps apk and its package database (/lib/apk/db/installed), every major SCA tool — Trivy, Grype, Snyk, Safeguard — has mature, well-tested support for enumerating Alpine packages, and you can apk upgrade inside a running container for a fast interim fix. Distroless has no package manager to run an in-place fix with; the only remediation path is rebuilding the image with an updated base digest, which is slower to execute but forces the reproducible-build discipline that most compliance frameworks (SOC 2, FedRAMP) actually want. Google's distroless project deliberately preserves a dpkg status file in the image specifically so scanners can still identify installed package versions even without a live dpkg binary — a design decision made explicitly to keep the images scannable despite having no shell to run a scanner's helper scripts inside.
So which base image should you actually choose?
Choose distroless when your primary concern is limiting what an attacker can do after a container compromise, and choose Alpine when you need in-container debuggability or apk-based runtime flexibility. Distroless's missing shell and package manager close off an entire category of post-exploitation techniques — no /bin/sh means no trivial reverse shell, no wget/curl for living-off-the-land data exfiltration, no package manager to abuse for persistence. That's a meaningful, measurable reduction in what MITRE ATT&CK calls "Living Off the Land" opportunities inside a container. Alpine, meanwhile, remains the better fit for teams that need kubectl exec debugging, custom runtime package installs, or musl-compatible static binaries, and its CVE history — one severe blank-password bug in 2019, patched apk-tools issues since — is manageable if you're patching promptly. Neither choice replaces scanning your actual application dependencies, which is where the majority of exploitable CVEs in any given image will be found regardless of base.
How Safeguard Helps
Whichever base image you standardize on, the base OS is rarely where your real exposure lives — it's in the application dependencies layered on top, and in knowing which of those CVEs are actually reachable from your code paths. Safeguard generates and ingests SBOMs across both Alpine (apk) and Debian-based distroless images so you get a single normalized inventory instead of two different scanning stories. Safeguard's reachability analysis then determines which flagged CVEs — in glibc, musl, OpenSSL, or your application libraries — are actually exploitable given your call graph, cutting through the noise that base-image switching alone never resolves. Griffin AI triages the remaining findings by real-world exploitability and business impact, and for confirmed, reachable issues Safeguard opens auto-fix pull requests that bump the affected package or base image digest, so remediation doesn't stall on manual patch research regardless of which base image your teams picked.