Skip to content

Portal | Level: L1: Foundations | Topics: Security Scanning, Docker / Containers | Domain: Security

Lab Runtime 06 — Trivy Vulnerability Scanning — Fail to Green

Objective

Understand Trivy vulnerability scanning via a document-based lab showing how to scan, triage, and remediate container image vulnerabilities.

This is a guided walkthrough rather than a traditional break/fix lab, because modifying real container images in a live cluster is messy. Instead, we build test images locally, scan them, and compare results.

Prerequisites

  • Docker installed and running
  • Trivy installed (or make trivy-scan available)
  • The grokdevops repo checked out

Steps

  1. Break: Run ./break.sh to build a container image from an older, vulnerable base (python:3.9-slim-buster) and scan it with Trivy. Observe the CRITICAL/HIGH vulnerabilities reported.
  2. Observe: Review the Trivy output. Note the CVE IDs, severity levels, and affected packages.
  3. Fix: Run ./fix.sh to build the image using the repo's actual Dockerfile (which uses a current, patched base image) and scan it.
  4. Verify: Run ./verify.sh to confirm the repo image has no CRITICAL/HIGH vulnerabilities.
  5. Teardown: Run ./teardown.sh to remove test images and temporary files.

Expected Observations

  • Trivy scan of the old base image (python:3.9-slim-buster) reports multiple CRITICAL and HIGH severity CVEs in OS-level packages (e.g., openssl, libc, zlib).
  • Trivy scan of the current repo image (using a patched base) reports zero CRITICAL/HIGH vulnerabilities.
  • The CVE list includes identifiers like CVE-20XX-XXXXX with affected package names, installed versions, and fixed versions.

Wrong Turns

  1. Patching individual packages inside the container — This is fragile and hard to maintain. Updating the base image is simpler and fixes all known vulnerabilities at once while keeping the dependency chain consistent.
  2. Ignoring CVEs or marking them as acceptable — Ignoring real vulnerabilities creates security risk. Exceptions should only be used for false positives or CVEs that genuinely do not apply to your workload.
  3. Only scanning in CI and never rebuilding — Scanning only at build time misses newly disclosed CVEs. Production images should be regularly rebuilt and rescanned to pick up patches in updated base images.

Minimal Explanation

Container images are built on base OS images that ship with system packages. Over time, security researchers discover vulnerabilities in these packages and assign CVE identifiers. Older base images (like Debian Buster) may reach end-of-life and stop receiving patches entirely. Trivy scans the image filesystem, reads the package database (e.g., dpkg status), and cross-references installed package versions against vulnerability databases. When you rebuild on a current, maintained base image, most CVEs disappear because the base image maintainers have already applied the security patches.

Transfer Pattern

  • Compliance audits: Security teams or auditors require proof that container images are free of known CRITICAL/HIGH CVEs before approving production deployment.
  • Supply chain security requirements: Frameworks like SLSA and organizational policies mandate regular vulnerability scanning and remediation as part of the software delivery pipeline.

See Also

  • training/library/guides/security-scanning.md
  • training/interview-scenarios/06-ci-vuln-scan-failed.md

Solution (spoilers)

See training/library/solutions/labs/lab-runtime-06.md for hints and explanation.

Teardown

./teardown.sh

Wiki Navigation

Prerequisites

  • Docker Exercises (Quest Ladder) (CLI) (Exercise Set, L0)

Related Content