Container image security: smaller images, fewer problems

Start from a minimal base

A full operating system image carries hundreds of packages your application never uses, each a potential vulnerability that will appear in scan reports and need triaging.

Distroless or minimal base images remove the shell and package manager entirely. This eliminates most reported vulnerabilities and makes an attacker's job considerably harder if they do get execution.

Build in stages

Use a multi-stage build so compilers, development dependencies and build tooling stay in the build stage and never reach the final image.

The runtime image should contain the application, its runtime dependencies and nothing else. This routinely reduces image size by an order of magnitude, which also speeds deployment.

Scan continuously, not once

• Scan at build time and fail on severities above your threshold.
• Re-scan images already in the registry — new vulnerabilities are disclosed after you build.
• Pin base images by digest so builds are reproducible.
• Generate a software bill of materials so you can answer “are we affected” quickly.

That last point matters more each year. When a widely used library has a serious disclosure, the organisations that answer within hours are the ones that already know what they ship.

Run with least privilege

Run as a non-root user, mount the filesystem read-only where possible, drop unnecessary capabilities and set resource limits.

These are configuration changes rather than engineering work, and together they meaningfully limit what a compromised container can do.

Managing the base image lifecycle

Base images age. A container built six months ago carries whatever vulnerabilities existed then, and it will keep carrying them until it is rebuilt, regardless of whether your application code changed.

Schedule periodic rebuilds of images that are still deployed, so patched base layers reach production without waiting for a feature release. This is straightforward to automate and is skipped surprisingly often.

Standardise on a small set of approved base images maintained centrally. An organisation with twenty different base images has twenty upgrade paths; one with three has three.