trivy for Container Image Scanning

trivy scans images for CVEs.

Basic usage

Trivy covers three surfaces with three commands. trivy image scans a container image and reports CVEs by severity with fixed versions and library context; trivy fs scans a filesystem or git repo for vulnerabilities; trivy config scans IaC manifests for misconfigurations.

• trivy image registry/repo:tag. Scans a container image; reports CVEs by severity, fixed versions, library context.
• trivy fs ./. Scans a local filesystem or git repo; useful for IaC and source code scanning.
• trivy config ./. Scans Terraform, Kubernetes manifests, Dockerfiles for misconfigurations.
• Per-surface command discipline. The three commands cover most security-scan paths; supports a consistent operator workflow.

CI integration

CI integration runs trivy at every layer of the build. Pre-build scans catch issues before image build; post-build scans give the comprehensive view including base-image vulnerabilities; severity gates fail the build on critical or high CVEs with documented escape valves for known-not-applicable issues.

• Pre-build scan. Trivy on the Dockerfile and dependencies; catches issues before image build.
• Post-build scan. Trivy on the built image; comprehensive view including base-image vulnerabilities.
• Severity gates. Fail the build on critical or high CVEs; configurable thresholds.
• Per-CVE escape valve. Documented exemptions for known-not-applicable issues; supports legitimate exceptions.

Ignoring known issues

Ignoring known issues needs structure. .trivyignore lists CVEs to skip for false positives or accepted risk; VEX attestations are the structured way to mark CVEs as not-applicable and are better than .trivyignore for compliance; periodic review catches ignores that no longer apply.

• .trivyignore file. Lists CVEs to ignore; used for false positives or accepted-risk vulnerabilities.
• VEX attestations. Structured way to mark CVEs as not-applicable; better than .trivyignore for compliance.
• Periodic ignore review. CVEs not-applicable last quarter may apply this quarter as the codebase evolves.
• Per-ignore documented justification. Each entry has a reason and a review date; supports audit and rotation.

Registry integration

Trivy integrates with registries to scan on push. Trivy server mode is a long-running scanner; pull-on-push triggers scans on every image push with results visible in the registry UI; cached scans reuse the trivy database locally so the same image layer doesn’t re-pay the scan cost.

• Trivy server mode. Long-running scanner; integrates with ECR, Harbor, GHCR.
• Pull-on-push scanning. Registry triggers scan on every image push; results visible in registry UI.
• Cached scans. Trivy database is cached locally and updated periodically; avoids redundant work for the same image layer.
• Per-registry integration. One integration per registry; supports consistent scanning across the supply chain.

Trivy vs alternatives

The alternatives have different trade-offs. Snyk is commercial with richer remediation suggestions and developer-tool integrations; Grype (Anchore) has a similar feature set with a different vulnerability database, and some teams run both for coverage; Trivy’s advantages are being open source, broad scanner support, and fast updates.

• Snyk. Commercial; richer remediation suggestions; integrates with developer workflow tools.
• Grype (Anchore). Similar feature set; different vulnerability database; some teams run both for coverage.
• Trivy advantages. Open source; broad scanner support (images, IaC, code, Kubernetes); fast updates.
• Per-stack tool fit. Pick by integration depth and budget; trivy as default unless a specific need pulls towards an alternative.