DevSecOps in Practice: Tools That Actually Catch Vulnerabilities - Part 5 - Container Scanning with Trivy

#docker #devops #tutorial #security

The previous parts secured the code and the infrastructure. This part secures the container image — the thing that actually runs in production.
When you build a Docker image, you're not just shipping your application.
You're shipping the entire base image underneath it — the OS, the system
libraries, the package manager, all of it. Every CVE in those packages is
now your problem.

Code repo: https://github.com/pkkht/devsecops-demo/

What container scanning is
Container scanning analyses a built Docker image for known vulnerabilities. It inspects the OS layer, every installed package, and the application dependencies, then cross-references each one against public CVE databases. The key insight: most of the vulnerabilities in a container image come from the base image, not from the application code. Choosing an old or full base image can introduce hundreds of vulnerabilities before you've written a single line of your own code.

The tool: Trivy
Trivy is an open source vulnerability scanner from Aqua Security. It scans container images, filesystems, git repositories, Kubernetes clusters, and more. It queries multiple vulnerability databases including the NVD, GitHub Advisory Database, and OS-specific advisories. It's free, fast, and requires no account or API key.

The demo Dockerfile
The Dockerfile in the repo has two intentional issues:

# ISSUE 1: Using python:3.8 (not slim, not alpine)
# An older, full base image with many OS-level packages = more CVE surface.
# The fix: use python:3.11-slim or python:3.11-alpine.
FROM python:3.8

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

# ISSUE 2: No USER directive — container runs as root
# Running as root means if the app is compromised, the attacker
# has root inside the container.
# The fix:
#   RUN adduser --disabled-password --gecos '' appuser
#   USER appuser

EXPOSE 5000
CMD ["python", "app.py"]

python:3.8 is a full Debian-based image. It includes everything — compilers, build tools, image processing libraries, the lot. Most of it is unnecessary for running a Flask API, but all of it adds CVE surface.

GitHub Actions workflow
Create .github/workflows/container-scan.yml:

name: Container Scan - Trivy

on:
  push:
    branches: ["**"]
  pull_request:
    branches: ["**"]

jobs:
  trivy:
    name: Trivy Container Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t devsecops-demo:${{ github.sha }} .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: devsecops-demo:${{ github.sha }}
          format: json
          output: trivy-report.json
          severity: CRITICAL,HIGH
          exit-code: 1

      - name: Upload Trivy Report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: trivy-report
          path: trivy-report.json

severity: CRITICAL,HIGH tells Trivy to only report and gate on CRITICAL and HIGH findings — ignoring MEDIUM and LOW keeps the noise manageable.
exit-code: 1 fails the build when findings are found.

What the pipeline found

The pipeline failed immediately.

The trivy-report.json artifact from the Actions run tells the full story.
Total: 1,747 vulnerabilities
OS layer (Debian 12.7): 1,736 vulnerabilities
CRITICAL: 185
HIGH: 1,551

Python packages: 11 vulnerabilities
HIGH: 11

OS layer findings
The python:3.8 base image ships with ImageMagick, which alone accounts for
185 CRITICAL findings. ImageMagick is an image processing library with a long history of CVEs. You almost certainly don't need it in a Flask API container, but because python:3.8 is a full Debian image, it's there anyway.

Python package findings
The application dependencies contributed 11 HIGH severity findings:

These overlap with what pip-audit found in Part 4 — Trivy is scanning the same packages but from inside the built image rather than from
requirements.txt. Both tools catching the same issues is a good sign.

A sample finding from the JSON report

{
  "VulnerabilityID": "CVE-2023-30861",
  "PkgName": "Flask",
  "InstalledVersion": "1.1.2",
  "FixedVersion": "2.2.5, 2.3.2",
  "Severity": "HIGH",
  "Title": "Flask vulnerable to possible disclosure of permanent session cookie"
}

The fix is simple

Both issues in the Dockerfile have straightforward fixes:
Switch to a slim base image:

# Before
FROM python:3.8

# After
FROM python:3.11-slim

python:3.11-slim is a minimal Debian image — no ImageMagick, no compilers, no build tools. The CVE count drops dramatically.

Add a non-root user:

RUN adduser --disabled-password --gecos '' appuser
USER appuser

The container no longer runs as root.
These two changes would eliminate the vast majority of the 1747 findings.
They are intentionally left in the demo so the pipeline has something real
to catch.

What we've built so far
Six layers now in place: