Docker Vulnerability Scanning

Every Docker image contains software: an operating system layer, language runtimes, and libraries. Security researchers discover flaws in this software every week, and each flaw receives a public identifier. Scanning checks your image against those public records and tells you which packages need an update.

What Is a Vulnerability

A vulnerability is a known weakness in a piece of software. The security community tracks them as CVEs, short for Common Vulnerabilities and Exposures. Each CVE has an ID such as CVE-2024-12345 and a severity rating.

Severity    Meaning
---------   ------------------------------------------
CRITICAL    fix right away
HIGH        fix soon
MEDIUM      plan a fix
LOW         fix when convenient

Think of a scanner as a building inspector. The inspector walks through every room, compares each item against a list of recalled products, and hands you a report. The inspector does not repair anything. You decide what to fix.

How a Scanner Works

Your image
    |
    v
1. Unpack the layers
2. List every package and version
3. Compare against a vulnerability database
4. Print a report of matches

Scanning With Docker Scout

Docker Desktop and the Docker CLI include a scanner called Docker Scout.

docker scout quickview my-app:1.0
docker scout cves my-app:1.0
docker scout recommendations my-app:1.0

The recommendations command suggests a newer base image that removes many findings at once.

Scanning With Trivy

Trivy is a free open source scanner that runs anywhere.

trivy image my-app:1.0
trivy image --severity HIGH,CRITICAL my-app:1.0
trivy image --exit-code 1 --severity CRITICAL my-app:1.0

The last command returns exit code 1 when it finds a critical flaw. Build pipelines use this code to stop a risky image from moving forward.

Reading a Report

Package     Installed   Fixed In   Severity   ID
----------  ----------  ---------  ---------  ---------------
openssl     3.0.2       3.0.13     HIGH       CVE-XXXX-XXXXX
zlib        1.2.11      1.2.13     MEDIUM     CVE-XXXX-XXXXX

The Fixed In column holds the most useful information. When it shows a version, an update removes the problem. An empty value means the maintainers have not released a fix yet.

Fixing Common Findings

Update the Base Image

Most findings come from the operating system layer. Rebuilding with a fresh base image removes many of them.

FROM python:3.12-slim      rebuild weekly to receive patches

Switch to a Smaller Base

Alpine and distroless images contain far fewer packages, so scans report fewer issues.

Remove Unneeded Tools

Compilers, package managers, and debugging tools belong in a build stage, not in the final image. Multi stage builds keep them out.

Update Application Dependencies

Libraries in requirements.txt or package.json show up in scans too. Raise their versions to patched releases.

Scanning in the Workflow

Write code -> Build image -> SCAN -> Push image -> Deploy
                              |
                  fail the build when CRITICAL flaws appear

Scan on every build and again on a schedule. A clean image today can show new findings next month because researchers keep discovering flaws in old software.

Handling Findings That Do Not Apply

Some reports list flaws in code your application never calls. Teams record these cases in an ignore file with a written reason and an expiry date, so the decision gets reviewed later.

# .trivyignore
CVE-XXXX-XXXXX

Common Mistakes

• Scanning once and never again.
• Chasing every low severity item while critical items wait.
• Pinning an old base image forever. Pin versions, and update the pin on a schedule.

Real-World Scenario

A team ships a Python service built on a two-year-old base image. A scan before a customer review reports forty findings, including six critical ones, all inside operating system packages. The team switches to the current slim base image and rebuilds. The count drops to three medium findings. The change required one edited line and zero code changes, because the application never depended on the old packages.

The lesson applies to nearly every project. Old base images collect findings steadily, and a regular rebuild removes most of them without effort.

Understanding False Alarms

A scanner reports every package that exists in the image, including ones your program never loads. A finding in a rarely used system tool may carry little real risk. Judge each finding by three questions: does the package run in your container, can an outside user reach it, and does a fix exist? Document your answers so the next reviewer sees the reasoning.