Solution: Lab Runtime 06 -- Trivy Fail to Green¶
SPOILER WARNING: Try to solve it yourself first.
Hint Ladder¶
Hint 1: This lab compares two Docker images: one built from an old base image, one from the current Dockerfile. Which has more vulnerabilities?
Hint 2: Run trivy image on both images. Compare the CRITICAL/HIGH counts.
Hint 3: The old base image (python:3.9-slim-buster) has known CVEs because Buster is an older Debian release with unpatched packages.
Hint 4: The fix is using the repo's current Dockerfile, which uses a newer base image. Run ./fix.sh to see the difference.
Minimal Solution¶
# Build with vulnerable base
docker build -t grokdevops:vulnerable --build-arg BASE=python:3.9-slim-buster .
trivy image grokdevops:vulnerable --severity CRITICAL,HIGH
# Build with current base
docker build -t grokdevops:safe .
trivy image grokdevops:safe --severity CRITICAL,HIGH
Explain¶
Symptom: Trivy reports CRITICAL/HIGH CVEs in the container image.
Evidence: trivy image output shows CVE IDs, affected packages, and fix versions.
Root cause: Older base images contain OS packages with known vulnerabilities. The fix is upgrading to a newer base image where the OS vendor has backported security patches.
Key insight: Container vulnerability scanning catches issues in the OS layer (apt packages), not in your application code. The most impactful fix is usually updating the base image, not patching individual packages.
Prevent¶
- Pin base images to specific digests, but regularly update them
- Add Trivy scanning to CI pipeline (fail on CRITICAL)
- Use slim/distroless base images to reduce attack surface
- Rebuild images regularly even without code changes (to pick up base image patches)