Why Your Docker Images Are Bloated with Vulnerabilities—and How to Slim Them Down

This article unexpectedly topped Hacker News, sparking a discussion about bloated Docker images and their security implications.

Vulnerability scanners generate many false positives; some findings can be fixed upstream, while others are irrelevant to the application.

Official base images on Docker Hub are rarely updated, shifting the patch‑management burden from ops teams to developers.

Adding RUN apt-get update && apt-get -y upgrade to every Dockerfile yields minimal security benefit and can make builds unreproducible.

Scanning Official Python Image

Using Docker’s built‑in scanning (Snyk Container) on a simple python:3.9 Flask app produced 358 vulnerabilities (54 high, 48 medium).

# latest stable at the time
FROM python:3.9

RUN pip install Flask

COPY server.py server.py

ENV FLASK_APP=server.py
ENV FLASK_RUN_PORT=5000
ENV FLASK_RUN_HOST=0.0.0.0

EXPOSE 5000

CMD ["flask", "run"]

The scan output listed low‑severity issues in libraries such as unbound, tiff, and high‑severity problems in gcc, djvulibre, and bluez.

Using a Slim Base Image

Switching to python:3.9‑slim reduced the findings to 69 vulnerabilities (14 high, 8 medium).

FROM python:3.9-slim

RUN pip install Flask

COPY server.py server.py

ENV FLASK_APP=server.py
ENV FLASK_RUN_PORT=5000
ENV FLASK_RUN_HOST=0.0.0.0

EXPOSE 5000

CMD ["flask", "run"]

Using Alpine

Building the same app on python:3.9‑alpine resulted in zero known vulnerabilities.

FROM python:3.9-alpine

RUN pip install Flask

COPY server.py server.py

ENV FLASK_APP=server.py
ENV FLASK_RUN_PORT=5000
ENV FLASK_RUN_HOST=0.0.0.0

EXPOSE 5000

CMD ["flask", "run"]

Non‑Distribution (Distroless) Image

A multi‑stage build using gcr.io/distroless/python3 yielded 37 vulnerabilities (6 high, 8 medium), a ~90% reduction compared to the default image.

# Build image
FROM python:3.7-slim AS build-env
RUN python -m pip install Flask

# Runtime image
FROM gcr.io/distroless/python3
COPY --from=build-env /usr/local/bin/flask /usr/local/bin/flask
COPY --from=build-env /usr/local/lib/python3.7/site-packages /usr/local/lib/python3.7/site-packages
WORKDIR /app
COPY server.py server.py
ENV PYTHONPATH=/usr/local/lib/python3.7/site-packages
ENV FLASK_APP=server.py
ENV FLASK_RUN_PORT=5000
ENV FLASK_RUN_HOST=0.0.0.0
EXPOSE 5000
CMD ["/usr/local/bin/flask", "run"]

Scanning a Scratch Go Image

A minimal scratch Go container also reported no vulnerable paths, demonstrating that eliminating the underlying distribution reduces the attack surface.

FROM scratch
COPY hello /
CMD ["/hello"]

Overall, smaller containers not only speed up builds and reduce storage/network usage but also improve security. Recommended practices include using slim, Alpine, or distroless base images, avoiding unnecessary tooling in Dockerfiles, and leveraging Kubernetes debug containers instead of embedding full debugging suites.