Hardening Container Base Images: From ubuntu:latest to a Minimal, Signed, Scannable Image

Problem

ubuntu:latest ships with over 200 packages. At any given point, a vulnerability scan with Trivy will report 50 or more CVEs, most of which are in packages your application never uses. This is the default starting point for most container deployments:

• A larger image means a larger attack surface. Every installed binary is a potential tool for an attacker who gains code execution inside the container.
• Shells (/bin/bash, /bin/sh) let an attacker run arbitrary commands interactively after gaining initial access.
• Package managers (apt, apk) let an attacker install additional tools (curl, wget, netcat) for lateral movement.
• Running as root by default means a container escape gives the attacker root on the host.
• Unsigned images mean you cannot verify that the image you are pulling is the one that was built. Supply chain attacks can inject malicious layers.

Most teams know they should use smaller images. Fewer teams actually do it, because the migration from ubuntu:latest to a minimal image breaks build processes, requires understanding the differences between musl and glibc, and demands changes to debugging workflows.

Target environments: Docker, containerd, Kubernetes. Languages covered: Go, Python, Node.js, Java.

Threat Model

• Adversary: Attacker who has achieved remote code execution inside a container (through an application vulnerability, a compromised dependency, or a deserialization flaw) and is attempting to escalate privileges, exfiltrate data, or move laterally.
• Access level: Code execution as the container process user (ideally non-root, but often root in unhardened deployments).
• Objective: Install tools for reconnaissance, establish a reverse shell, access secrets mounted in the container, or escape the container to the host.
• Blast radius: Single container initially. With a shell and root access, the attacker can read mounted secrets, query the Kubernetes API (if a service account is mounted), and attempt container escape to the node.

Configuration

Base Image Comparison

Multi-Stage Build: Go Application

# Build stage - full toolchain
FROM golang:1.23-bookworm AS builder

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download

COPY . .
# CGO_ENABLED=0 produces a static binary that runs on scratch/distroless
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags="-s -w" -o /app/server ./cmd/server

# Runtime stage - minimal image, no shell, no package manager
FROM gcr.io/distroless/static:nonroot

COPY --from=builder /app/server /server

USER nonroot:nonroot
EXPOSE 8080

ENTRYPOINT ["/server"]

Multi-Stage Build: Python Application

# Build stage - install dependencies
FROM python:3.12-slim-bookworm AS builder

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

# Runtime stage - distroless Python
FROM gcr.io/distroless/python3-debian12:nonroot

COPY --from=builder /install /usr/local
COPY --from=builder /app /app

WORKDIR /app
COPY . .

USER nonroot:nonroot
EXPOSE 8000

ENTRYPOINT ["python3", "app.py"]

Multi-Stage Build: Node.js Application

# Build stage
FROM node:22-bookworm-slim AS builder

WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production

# Runtime stage
FROM gcr.io/distroless/nodejs22-debian12:nonroot

COPY --from=builder /app/node_modules /app/node_modules
COPY . /app

WORKDIR /app

USER nonroot:nonroot
EXPOSE 3000

ENTRYPOINT ["app.js"]

Multi-Stage Build: Java Application

# Build stage
FROM eclipse-temurin:21-jdk-jammy AS builder

WORKDIR /app
COPY . .
RUN ./gradlew build --no-daemon -x test

# Runtime stage - distroless Java
FROM gcr.io/distroless/java21-debian12:nonroot

COPY --from=builder /app/build/libs/app.jar /app.jar

USER nonroot:nonroot
EXPOSE 8080

ENTRYPOINT ["app.jar"]

Running as Non-Root

Every runtime image should use a non-root user. Use numeric UIDs for Kubernetes compatibility with runAsNonRoot:

# Numeric UID/GID for K8s runAsNonRoot enforcement
USER 65532:65532

Distroless images include a nonroot user (UID 65532) by default. For Alpine-based images, create one:

FROM alpine:3.20
RUN addgroup -S appgroup && adduser -S appuser -G appgroup -u 65532
USER 65532:65532

Removing Shells and Package Managers

For Alpine-based images where you want to keep the small size but remove attack tools:

FROM alpine:3.20 AS runtime

# Install only what the application needs
RUN apk add --no-cache ca-certificates tzdata \
    && rm -rf /sbin/apk /usr/bin/apk \
    && rm -rf /lib/apk /etc/apk \
    && rm -rf /bin/sh /bin/ash /bin/busybox

# The shell removal above means you cannot use shell-form CMD.
# Use exec form only:
ENTRYPOINT ["/app/server"]

Image Signing with Cosign

Sign images after building to establish a chain of trust from build to deployment:

# Install cosign
go install github.com/sigstore/cosign/v2/cmd/cosign@latest

# Keyless signing (uses Sigstore transparency log)
# Requires OIDC identity (GitHub Actions, GitLab CI, or local browser)
cosign sign registry.example.com/myapp:v1.2.3

# Key-based signing (for air-gapped environments)
cosign generate-key-pair
cosign sign --key cosign.key registry.example.com/myapp:v1.2.3

# Verify before deployment
cosign verify registry.example.com/myapp:v1.2.3 \
    --certificate-identity=github-actions@example.com \
    --certificate-oidc-issuer=https://token.actions.githubusercontent.com

In Kubernetes, enforce signature verification with a policy engine:

# Kyverno policy to require cosign signatures
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-signed-images
spec:
  validatingAdmissionPolicy: true
  rules:
    - name: verify-signature
      match:
        resources:
          kinds: ["Pod"]
      verifyImages:
        - imageReferences: ["registry.example.com/*"]
          attestors:
            - entries:
                - keyless:
                    subject: "github-actions@example.com"
                    issuer: "https://token.actions.githubusercontent.com"

Scanning with Trivy in CI

Add vulnerability scanning to your CI pipeline and fail builds on critical findings:

# GitHub Actions example
- name: Scan image with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: "registry.example.com/myapp:${{ github.sha }}"
    format: "table"
    exit-code: "1"
    severity: "CRITICAL,HIGH"
    ignore-unfixed: true

For accepted risks, create a .trivyignore file:

# .trivyignore - accepted vulnerabilities with justification
# CVE-2024-1234: Not exploitable in our configuration (no network exposure)
CVE-2024-1234
# CVE-2024-5678: Fix not yet available upstream, monitoring for update
CVE-2024-5678

Expected Behaviour

After migrating from ubuntu:latest to a hardened base image:

• docker image ls shows image size reduced from 200-500 MB to 2-30 MB depending on the base
• trivy image myapp:latest reports zero critical/high CVEs (for distroless/Chainguard bases)
• docker exec -it container /bin/sh fails with “executable file not found” (no shell in distroless)
• Container runs as non-root: docker exec container whoami returns nonroot or the numeric UID
• cosign verify succeeds for signed images and fails for unsigned/tampered images
• Application starts and serves traffic identically to the ubuntu-based version

Trade-offs

Failure Modes

When to Consider a Managed Alternative

Transition point: When you maintain internal base images across more than 3 teams, or when vulnerability scanning every image in every pipeline generates 100+ CVE alerts per week without prioritization, leading to alert fatigue.

What managed providers handle:

Chainguard (#44) provides pre-hardened container images that are rebuilt daily from source, contain zero known CVEs at build time, and are signed with Sigstore. Instead of maintaining your own base image hardening pipeline, you pull cgr.dev/chainguard/python:latest and get a minimal, signed, scanned image with no effort.

Snyk (#48) Container provides prioritized vulnerability management that distinguishes between CVEs that are exploitable in your configuration and those that are not. This reduces alert volume from hundreds of CVEs to the handful that actually matter for your deployment.

Docker Scout (#45) integrates scanning directly into Docker Desktop and Docker Hub, providing vulnerability visibility without adding a separate scanning tool to your pipeline.

What you still control: Base image selection and Dockerfile structure remain your decisions regardless of tooling. A managed scanning tool tells you about vulnerabilities; you still need to build minimal images, run as non-root, and remove unnecessary packages.

Automation path: For self-managed infrastructure, integrate Trivy scanning and cosign signing into your CI pipeline using the examples in this article. For fleet-wide base image governance, the premium Dockerfile template pack provides hardened, tested base images for Go, Python, Node.js, and Java with CI integration examples.