Find the known vulnerabilities in your own Docker images
Every Docker image you build quietly carries hundreds of other people's packages: the operating system underneath it, the language runtime, and every library you install. Any one of them can have a published, known security flaw, and you cannot fix what you cannot see. In this mission you install Trivy, a free scanner, and point it at an old image on your own machine. You read the report it produces, learn what the severity numbers mean and which findings have a fix, then you write a small Dockerfile, scan it, rebuild it on a current base image and watch the vulnerability count fall. Everything here runs against images you built or pulled yourself. It is defensive supply-chain work, the kind that stops a known flaw reaching production, and it pairs with Build a hacking lab, which set up the Docker you will use.
- Docker running on your PC. The Level 0 companion Build a hacking lab installs Docker Desktop on Windows 11 with the WSL2 backend used here, and covers the terminal basics if they are new to you. macOS and Linux work the same way with the same commands
- A terminal with the
dockercommand available. On Windows this mission runs its scanner inside the WSL2 Ubuntu shell that Docker Desktop already set up, where bothdockerand the scanner live together; on macOS or Linux your normal terminal is fine - About 1GB of free disk space: roughly 400MB for the two python base images, a little for the images you build, and about 250MB for Trivy's vulnerability database
- An internet connection the first time, so Trivy can download its vulnerability database and Docker can pull the base images. After that a scan works offline until the database goes stale
Why scan an image at all
Understand what a container image is really made of, and why a scanner is the only practical way to know what is inside one, before you install anything.
A Docker image is the frozen template your containers start from: a stack of read-only layers piled on top of each other. The bottom layer is usually a whole small operating system (a trimmed Debian or Alpine Linux), the next is a language runtime like Python or Node, and the top layers are your own code and the libraries you install. When you write
FROM python:3.8-slim, you are not starting from nothing. You are inheriting an entire Debian system and a Python build that other people assembled, with every package they chose to include.That inheritance is the point of containers and also the risk. Each of those inherited packages is software, and software has bugs, some of them security bugs. A CVE (Common Vulnerabilities and Exposures) is a single published, catalogued security flaw in a specific piece of software, with a unique id like CVE-2024-6345. There is a global, free catalogue of them. When a flaw in, say, OpenSSL or setuptools is found and published, every image that still ships the affected version now carries a known, named weakness, whether or not anyone building on that image ever knew those packages were there.
This is what people mean by supply-chain security. You did not write OpenSSL, but if your image ships a vulnerable copy of it, your service is exposed through it. The attacker does not need a clever new trick; they look up which images use an old base, read the public CVE, and walk in through a hole that was documented months ago. The defence is unglamorous and effective: know what is in your images, and keep the known-vulnerable parts patched.
You cannot do that by reading. A slim Python image contains a hundred-odd operating-system packages before you add a single line of your own, and each has its own version and its own list of published flaws. A scanner does the one job a human cannot: it reads the exact version of every package baked into an image, looks each one up in the CVE catalogues, and prints what matches. That is the whole of this mission. You will do it to images you built or pulled yourself, which is ordinary, lawful engineering work.
TipScanning your own images is the defensive opposite of the attacking lessons in this track, and it needs no lab rules of its own: an image on your disk is yours to inspect. The one line worth keeping from Build a hacking lab still holds in spirit. You scan and patch systems you own or are responsible for, which here means your own images.
FROM python:3.8-slim can carry hundreds of known vulnerabilities you never wrote, and why a scanner is the practical way to find them.