Docs

Security Scanning with Trivy

What this screen is for

Scanning a built image for known vulnerabilities, and reading the result well enough to decide whether to ship it.

Before you start

To do this You need
Run and read scans signed in

Opening it

Tools › Security Scanner, at /developer-tools/trivy-report.

The Image Builder integrates with Trivy to scan your Dockerfiles for security vulnerabilities before deployment.

📸 Screenshot Placeholder: A scan result with findings. Mark: (1) the severity breakdown, (2) a high-severity finding, (3) whether it originates in the base image, (4) the detail view.

How Scanning Works

When you click “Validate Dockerfile”, a GitHub Actions workflow is triggered that:

  1. Retrieves the project code and creates the Dockerfile in the repository
  2. Builds a Docker image from the Dockerfile
  3. Pushes the image to Docker Hub
  4. Scans the image with Trivy for vulnerabilities
  5. Generates a detailed JSON report

Timeline: 2–5 minutes depending on image complexity.

Understanding Results

Vulnerabilities are categorized by severity:

Severity Description
CRITICAL Severe vulnerabilities requiring immediate attention
HIGH Significant vulnerabilities that should be addressed
MEDIUM Moderate risk vulnerabilities
LOW Minor vulnerabilities with limited impact

Validation criteria:

  • Validated: Less than 2 CRITICAL and less than 10 HIGH vulnerabilities
  • Not Validated: Exceeds the thresholds above

Detailed Reports

Click “View Detailed Report” after a scan to open the full Trivy Report page. It includes:

  • Summary statistics — Total vulnerabilities, affected packages, average CVSS score
  • Severity breakdown — Count by severity level
  • Vulnerability table — Searchable list with CVE IDs, package names/versions, fixed versions, CVSS scores, and reference links

Scenario

A scan comes back with a long list and a deadline.

  1. Sort by severity and stop reading after the high ones. A list of low findings is not a reason to delay a release, and treating it as one is how teams learn to ignore scans entirely.
  2. For each high finding, check whether it is in your code or the base image. They have completely different fixes, and most findings are the base image.
  3. Base image findings usually go away by moving to a newer tag of the same image. Try that before anything else — it is one line.
  4. Findings in your dependencies need a version bump; findings with no fix available need a decision, recorded, not a silent pass.
  5. Re-scan after changing anything. A fix you did not verify is a belief.
  6. Where you ship with known findings, write down why. The next person to read this scan should not have to re-derive your reasoning.

When it doesn’t work

Symptom Cause How to check Fix
Every image reports findings Base images carry known CVEs; that is normal The severity split Focus on high; do not expect zero
A finding has no fix Not all CVEs have patched versions The finding detail Decide and record; do not silently ignore
Re-scan shows the same result The image was not rebuilt after the change The image tag Rebuild, then re-scan

Next