How to Scan Docker Compose Images for Vulnerabilities With Trivy

When you deploy services with Docker Compose, the Compose file names the images those services use and may also define settings such as host mounts or privileged access. Trivy scans container images for known vulnerabilities in their contents. An image scan does not review every setting in the Compose file, so check the images and the Compose configuration as separate targets.

To scan a Compose project's images, first validate the Compose configuration. Build images defined locally and pull images from registries, then pass the image names Compose selects to Trivy. The steps below show how to do that and how to make selected findings fail a CI job.

Scan the images resolved by Compose

Match the deployment by using its Compose files and project settings, along with the same profiles and environment variables. These inputs affect which services are active and which image names Compose resolves. Docker’s docker compose config command shows the configuration after Compose applies those inputs. Its --images option prints the image names.

For services that Compose builds, set an explicit image: name in the Compose file. That gives the build output a clear name to scan. Then run:

docker compose -f compose.yaml config --quiet
docker compose -f compose.yaml build
docker compose -f compose.yaml pull --ignore-buildable

images="$(docker compose -f compose.yaml config --images | sort -u)"
scan_failed=0

while IFS= read -r image; do
  [[ -z "$image" ]] && continue

  if ! trivy image --scanners vuln --severity HIGH,CRITICAL --exit-code 1 "$image"; then
    scan_failed=1
  fi
done <<< "$images"

exit "$scan_failed"

config --quiet checks the Compose configuration, build builds services with build definitions, and pull --ignore-buildable retrieves registry images while skipping images Compose can build. Docker documents that pull retrieves images without starting containers. The build and pull steps make the images available locally for Trivy.

The script scans each distinct image name. If a scan fails, it continues with the other images and exits with a nonzero status after the loop. Check the image names Compose prints before relying on the results, especially for services that only define a build: Compose behavior can depend on the CLI version and service configuration. An explicit image: name removes ambiguity about the intended build output.

For a single image, run trivy image myorg/api:dev. Trivy’s image scanner checks for known vulnerabilities in image contents. Vulnerability and secret scanning are enabled by default; the example uses --scanners vuln to limit the scan to vulnerabilities.

Set a CI threshold and keep the report

Trivy returns exit status zero by default even when it finds vulnerabilities. In the Compose example, --severity HIGH,CRITICAL selects the severities to report, and --exit-code 1 makes matching findings produce a nonzero status. Trivy’s exit-code settings let you use that status to fail a CI job. The threshold is a policy choice: this example does not fail on findings below High.

For a machine-readable report, scan an image with:

trivy image --scanners vuln --format json --output api-trivy.json myorg/api:dev

Keep the report with the image reference, scan time, Trivy version, platform, severity threshold, and any ignored-finding settings. A tag such as myorg/api:dev can point to different image contents over time; recording an immutable image digest makes the scan target easier to identify. Trivy supports platform selection with --platform; its documented default is linux/amd64, so specify the target platform when it differs.

Options such as --ignore-unfixed change which findings appear. If you use them, record that choice with the report. A clean report means Trivy found no matching issues with the selected scanner and platform, using the selected database and filtering policy. It does not prove that an image contains no vulnerabilities.

Check Compose settings separately

An image vulnerability scan does not evaluate Compose service settings such as privileged mode, host mounts, or added Linux capabilities. Trivy’s current infrastructure-as-code coverage lists Dockerfiles and generic YAML support, but does not list Compose as a dedicated configuration type. Generic YAML scanning has no built-in checks by default.

You can scan Compose YAML with custom Rego policies, or rules that you write for Trivy to check. For example:

trivy config \
  --misconfig-scanners=yaml \
  --config-check ./trivy-checks/compose.rego \
  --check-namespaces user \
  compose.yaml

This command does not supply Compose security rules on its own. Write and maintain policies for the settings you want to check, and validate them against your project’s Compose structure. Trivy can also check Dockerfiles and image metadata, but those checks do not replace review of Compose service settings.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com