liveBook · Manning

Vulnerability scanning

As explained in Learn Docker in a Month of Lunches, Second Edition

Security scanning is automated analysis of software or container images for known security vulnerabilities.

A container image can work correctly and still contain components with known security vulnerabilities. Vulnerability scanning checks images against known problems before they are used or deployed. Official images and images from verified Docker Hub publishers undergo security scanning, but organizations can also scan the golden images they build from those bases. section 5.5 section 17.2

Scan a base image with Trivy

Create a cache volume, then run Trivy in a container: docker volume create trivy-cache docker run -v trivy-cache:/root/.cache -it diamol/trivy:2e image --scanners vuln diamol/openjdk:2e The first scan takes longer because Trivy downloads vulnerability databases. The volume caches them for later runs. To focus on higher-severity findings, add `--severity HIGH,CRITICAL` before the image name. section 17.2

Use the findings to make a deployment decision:

  • Check the affected components, severity, vulnerability link, and whether a newer component version fixes the problem. Results can change as vulnerability databases are updated. section 17.2
  • Update vulnerable components or block deployment when a finding matters to your application. If you accept a specific problem, Trivy supports an ignore file; filtering low-severity findings is a separate choice. section 17.2
  • Add scanning to CI so a build can fail when checks find problems. Digital signing is a separate, later step that establishes image provenance. section 11.5

Trivy can also scan a remote Git repository for known vulnerabilities. Its separate misconfiguration scanner checks configuration such as Dockerfiles and Kubernetes manifests; that is not the same check as an image vulnerability scan. section 17.2

# create a volume to use as a data cache:
docker volume create trivy-cache
# run a vulnerability scan on the book's OpenJDK image:
docker run -v trivy-cache:/root/.cache `
 -it diamol/trivy:2e image --scanners vuln diamol/openjdk:2e
# run the same scan but ignore low severity problems:
docker run -v trivy-cache:/root/.cache `
 -it diamol/trivy:2e image --scanners vuln `
 --severity HIGH,CRITICAL diamol/openjdk:2e
# and finally ignore specific problems we have accepted:
docker run -v trivy-cache:/root/.cache `
 -it diamol/trivy:2e image --scanners vuln `
 --severity HIGH,CRITICAL --ignorefile /sample.trivyignore `
 diamol/openjdk:2e

Compare the full image-scan commands for all findings, HIGH and CRITICAL findings, and findings filtered through an ignore file. section 17.2

How Learn Docker in a Month of Lunches, Second Edition covers it

How deep it goes
Walks through Trivy commands, cache setup, severity filtering, and finding assessment; does not explain scanner internals.
Examples
Scans an OpenJDK image with containerized Trivy, then filters by severity or an ignore file.
What it assumes
Assumes basic familiarity with Docker images and commands; provides the commands needed to run Trivy in a container.
What you can do after
Apply it via Trivy to scan an image and assess whether findings require updates, deployment blocking, or acceptance.
How it connects
Connects scanning to base images, golden images, CI pipelines, digital signing, and software supply-chain security.

Also explained in

Compare how 2 books explain vulnerability scanning →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Learn Docker in a Month of Lunches, Second Edition. The section links point to the parts of the book it draws on.