Why Your Base Image Matters: The Foundation of Container Security

Blog

Why Your Base Image Matters: The Foundation of Container Security

Jonny Rivera

December 23, 2025

When building a house, you wouldn’t build on a cracked foundation. Yet, in the world of container development, that is precisely what happens when engineering teams build applications on top of unverified, public base images.

For most teams, the process begins by searching a public registry for a pre-existing image, typically built on Alpine, Debian, or Ubuntu, to serve as the base layer. While convenient, these community-maintained images are often bloated, outdated, and ridden with unpatched vulnerabilities and misconfigurations. If your base image is compromised, every container derived from it inherits that risk.

The Distroless Difference

To truly secure the software supply chain, you must shrink the attack surface. This starts with using a “distroless” base image.

Unlike standard distributions that package unnecessary utilities, a distroless image contains only the application and its runtime dependencies. Distroless Images strip away the vast majority of bundled software, meaning:

No Shells: Attackers cannot efficiently run scripts or execute commands if they gain access to the system.
No Package Managers: There is no easy way for bad actors to install malicious tools.
No Debugging Tools: Sensitive information and internal workings remain obscured.

ActiveState’s Custom Base Layer

ActiveState Secure Containers are built on a custom distroless foundation designed for maximum security and a minimal footprint. Instead of relying on upstream Linux distributions, ActiveState compiles only the required base components such as Glibc directly from source.

This approach delivers three critical advantages:

Reduced Attack Surface: By removing everything unnecessary, there are fewer potential vulnerabilities for attackers to exploit.
Total Visibility: Compiling from source ensures that only vetted components are included, providing complete control over the image’s contents.
Streamlined Maintenance: With fewer moving parts, the image is smaller, faster to pull, and significantly easier to patch and maintain.

Secure from the Start

A secure container requires a safe beginning. By shifting to a hardened, distroless base image, DevSecOps teams can proactively reduce the chance of vulnerabilities existing in the first place, rather than fighting them after deployment.

Why Choose ActiveState?

s a provider of managed services, your time is your most valuable asset. By starting with the most secure foundation, you reduce the risk of a high-cost security incident, protecting your business from the hundreds of millions of dollars in fines that security breaches incur in regulated industries.

Download the ActiveState Container Hardening Guide to see how a custom base image can transform your security posture.

Frequently Asked Questions

What is a distroless base image and why does it improve container security?

A distroless base image contains only the application and its required runtime dependencies — nothing else. Standard Linux distributions package shells, package managers, debugging tools, and other utilities that have no role in running a containerized application but significantly expand the attack surface. A distroless image removes all of it. Without a shell, an attacker who gains access to the container cannot execute scripts or commands. Without a package manager, they cannot install additional malicious tools. Without debugging utilities, internal system state is obscured. The result is a container with far fewer components to exploit, patch, and maintain — which makes the security posture easier to establish and easier to hold over time.

Why are public base images from Docker Hub and similar registries a security risk?

Public base images are community-maintained and optimized for general-purpose use and convenience, not for minimized security footprint. They typically include dozens or hundreds of packages that most applications never use, each carrying its own dependency tree and vulnerability history. They are frequently out of date at the time of publication, and they accumulate new vulnerabilities continuously after publication as new CVEs are disclosed against the components they include. When your team pulls a public image and builds on top of it, every vulnerability in that image is inherited by every container derived from it — including vulnerabilities in components your application never touches. The security work you apply at your layer cannot remediate risk that was baked in below it.

What does building a base image from source actually mean, and why does it matter?

Building from source means compiling the required base components — such as Glibc — directly from their upstream source code, rather than pulling a pre-built binary from a public distribution. This gives you complete, verifiable control over exactly what is in the image: which components, which versions, which compilation flags, and which dependencies. It eliminates the trust-the-binary problem inherent in pulling pre-built images from public registries, where the provenance of what was compiled and how is not verifiable. It also makes the image auditable — every component is known, documented, and traceable — which is the requirement regulators and auditors are increasingly asking organizations to demonstrate. A pre-built public image cannot provide the same level of documented assurance, because the build process that produced it is outside your control and often not fully documented.