trivy-image
Configures and runs Trivy for container image scanning: Aqua Security's all-in-one scanner combining vuln + secret + misconfiguration + license detection in one pass; `trivy image {image}` with --severity HIGH,CRITICAL filter; --format sarif/json (incl. scan-embedded CycloneDX; for standalone SBOM generation see syft-generation + cyclonedx-format); .trivyignore CVE suppression file; --ignore-unfixed for actionable filter; --scanners vuln/misconfig/license/secret toggle. Use when the team wants a single tool covering container image security across multiple dimensions, not for producing a standalone CycloneDX SBOM.
Install with skills.sh (any agent)
npx skills add testland/qa --skill trivy-imagetrivy-image
Overview
Per trivy.dev/latest/docs/target/container_image/ (opens in new window):
Trivy is Aqua Security's open-source scanner. Distinguishing feature: all-in-one - one CLI invocation covers vuln + secret + misconfig + license scanning. By contrast, syft-generation
Per tv-img (opens in new window) the scanner toggles:
| Scanner | Default? | Use |
|---|---|---|
vuln | yes | Known CVEs in OS + language packages |
secret | yes | Exposed credentials (env vars, config files) |
misconfig | no | Docker / Kubernetes config best-practices |
license | no | License compliance scanning |
When to use
Step 1 - Install
Common install paths:
# Homebrew (macOS / Linux)
brew install trivy
# Docker (zero-install for CI)
docker pull aquasec/trivy:latest
# Linux APT
sudo apt-get install trivy
# RPM
sudo dnf install trivyStep 2 - Basic image scan
Per tv-img (opens in new window):
# Default: vuln + secret scan
trivy image python:3.4-alpineExample with multiple toggles:
# All scanners (vuln + secret + misconfig + license)
trivy image --scanners vuln,secret,misconfig,license python:3.4-alpine
# Vuln-only (fastest, default if --scanners omitted defaults to vuln+secret)
trivy image --scanners vuln python:3.4-alpineStep 3 - Severity filtering
Per tv-img (opens in new window):
trivy image --severity HIGH,CRITICAL python:3.4-alpineSeverity levels: UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL.
Combined with exit-code-on-finding:
trivy image --severity HIGH,CRITICAL --exit-code 1 python:3.4-alpineExit code semantics: 0 = no findings at the configured severity; 1 = findings present.
Step 4 - Output formats
Per tv-img (opens in new window):
| Format | Use |
|---|---|
json | For multi-scanner finding prioritization |
sarif | GitHub Code Scanning upload |
cyclonedx | CycloneDX SBOM with vuln annotations |
spdx-json | SPDX SBOM (vuln-only metadata) |
template | Custom Go template |
| (default) | Table format human-readable |
trivy image --format json --output trivy-image.json my-image:1.0
trivy image --format sarif --output trivy-image.sarif my-image:1.0
trivy image --format cyclonedx --output trivy-cyclonedx.json my-image:1.0Step 5 - --ignore-unfixed for actionable filter
Per tv-img (opens in new window), --ignore-unfixed excludes vulnerabilities without an available fix - the practical first-line filter for actionable findings:
trivy image --ignore-unfixed python:3.4-alpineCombine with a severity threshold for the recommended PR-blocking config (fail only on actionable, high-severity vulns):
trivy image --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 my-image:1.0Step 6 - Secret scanning
Per tv-img (opens in new window):
"Secret detection runs automatically. The tool scans for exposed credentials and sensitive data, particularly in environment variables."
Secret findings appear alongside vuln findings in the same report. For deeper secret-scanning patterns, see gitleaks-scanning
Step 7 - Misconfiguration scanning
Per tv-img (opens in new window):
trivy image --scanners misconfig --severity HIGH,CRITICAL my-image:1.0Detects Docker / Kubernetes config patterns matching CIS Benchmarks
For comprehensive IaC scanning (not just image-internal config), use checkov-policy
Step 8 - False-positive triage (MANDATORY)
Per tv-img (opens in new window): "Use a .trivyignore file to suppress specific findings. Place this file in your project directory with CVE IDs or vulnerability identifiers you wish to exclude."
Suppression mechanisms:
| Mechanism | Use |
|---|---|
.trivyignore file | Per-CVE / per-misconfig-rule ID list |
--ignore-unfixed flag | Filter to actionable findings only |
--vex (VEX file) | Standardized status assertions (CycloneDX-VEX or OpenVEX) |
--ignore-policy Rego policy | Programmatic ignore via OPA Rego |
.trivyignore example:
# .trivyignore
# Reason: log4j-core 2.14.x bundled but not loaded at runtime
# (verified via dependency tree analysis)
# Approved-by: alice@example.com
# Re-review-date: 2026-09-15
CVE-2021-44228
CVE-2021-45046
# Misconfiguration ignores
DS013
KSV001Justification template (mandatory): every entry in .trivyignore should be preceded by # Reason: ... # Approved-by: ... # Re-review-date: ... comment block.
For richer programmatic suppression, use OpenVEX:
trivy image --vex sbom.openvex.json --severity HIGH,CRITICAL my-image:1.0The VEX file's per-CVE assertions (not_affected etc.) filter the output.
Cadence: every quarter, audit .trivyignore; expired re-review-date entries removed.
Step 9 - CI integration
Wrap the CLI with the aquasecurity/trivy-action GHA to scan the built image and upload SARIF to GitHub Code Scanning. The full GitHub Actions workflow is in references/ci-and-composition.md.
Step 10 - Composition with sister tools
Trivy is the all-in-one first line; compose it with syft-generation for a standalone SBOM, grype-scanning for cross-DB consensus on findings, and checkov-policy for deeper IaC scanning. The full composition table is in references/ci-and-composition.md.
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
Skip --ignore-unfixed | Stuck findings (no fix available) flood report | Always for PR gating (Step 5) |
.trivyignore without justification comment | No audit trail | Mandatory template (Step 8) |
| Run all scanners on every PR | Slow; misconfig + license noise on small changes | Default vuln+secret on PR; full scan nightly |
| Skip severity filter | LOW noise drowns CRITICAL signal | --severity CRITICAL,HIGH for PR (Step 3) |
Pin to aquasec/trivy:latest Docker tag | Breaking changes mid-release | Pin specific version |
Limitations
References
trivy-image CI integration and tool composition
View source (opens in new window)trivy-image CI integration and tool composition
Extracted from trivy-image. The SKILL.md spine keeps the scan commands inline; the full CI workflow and the sister-tool composition table live here.
CI integration
jobs:
trivy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- run: docker build -t my-app:${{ github.sha }} .
- uses: aquasecurity/trivy-action@master
with:
image-ref: my-app:${{ github.sha }}
format: sarif
output: trivy.sarif
severity: CRITICAL,HIGH
ignore-unfixed: true
exit-code: 1
- uses: github/codeql-action/upload-sarif@v3
if: always()
with: { sarif_file: trivy.sarif }The aquasecurity/trivy-action GHA wraps the CLI plus SARIF upload.
Composition with sister tools
| Sister tool | Use |
|---|---|
syft-generation | Generates standalone SBOM (Trivy embeds SBOM gen but exposes it less) |
grype-scanning | Alternative scanner; cross-DB consensus on findings |
cyclonedx-format, spdx-format | Reference for the SBOM formats Trivy outputs |
checkov-policy | Cross-plugin: deeper IaC scanning vs Trivy's image-internal misconfig |
Related skills
cyclonedx-format
Reference for the CycloneDX v1.6 software bill of materials (SBOM) specification - OWASP-curated, security-focused format covering software components, services, dependencies, vulnerabilities, formulation, machine learning models, and SaaS BOMs; supports XML / JSON / Protobuf encodings; per-language generators for npm, pip, Maven, Gradle, Go, etc.; integrates with CI via generate + sign + attest workflow. Use when the user asks to generate or write a software bill of materials / SBOM in CycloneDX form, or when the team adopts CycloneDX as its primary SBOM format (preferred for security-focused use cases vs SPDX's licensing focus).
grype-scanning
Scans for vulnerabilities using Anchore Grype: `grype sbom:./sbom.json` / `grype {image}` / `grype dir:./` across OS-package + language-package ecosystems (Alpine / Debian / Ubuntu / RHEL / Amazon Linux / Ruby / Java / JavaScript / Python / .NET / Go / PHP / Rust). `.grype.yaml` per-CVE and per-package ignore rules with mandatory `expires:` dates and reachability justification (the Grype-native suppression path, distinct from standalone VEX document authoring in vex-author); EPSS + KEV + risk-score prioritization; OpenVEX assertion filtering; `--fail-on high/critical` CI gate. Use when the team wants Grype-native vuln scanning, or pairs with Syft (syft-generation) for an SBOM-driven workflow.
sbom-diff
Compares two CycloneDX or SPDX SBOMs to surface net-new, removed, and version-changed components between image or build versions; uses cyclonedx-cli diff for structured output and syft-based generation for the input SBOMs; gates CI on net-new component introduction; enables supply-chain alerting when unexpected dependencies appear across releases. Use when the team needs to detect dependency drift between container image builds, release candidates, or dependency-update branches.
spdx-format
Reference for the SPDX (Software Package Data Exchange) v2.3 + v3.0 SBOM specification - Linux Foundation-curated, license-focused format covering packages, files, snippets, relationships, license declarations, and (in 3.0) AI / dataset / build / security profiles; supports Tag-Value / JSON / YAML / RDF / Spreadsheet encodings; preferred by US Federal procurement (NIST guidance) and Linux distros. Use when the team's SBOM consumer requires SPDX format (federal procurement, Linux Foundation members, license-compliance focus).
syft-generation
Generates Software Bill of Materials (SBOMs) using Anchore Syft - supports container images / directories / archives across OCI / Docker / Singularity formats; output formats CycloneDX-JSON / SPDX-JSON / Syft-JSON / table / GitHub-JSON; pairs with `grype-scanning` for SBOM-driven vuln scanning. Use when the team needs SBOM artifacts for compliance (US EO 14028, EU CRA, FDA medical-device guidance) or as input to vuln scanners.
vex-author
Authors and validates OpenVEX documents - produces `not_affected`, `affected`, `fixed`, and `under_investigation` statements with justification codes using `vexctl create`; attaches VEX assertions to container images; outputs `.openvex.json` files consumed on a downstream VEX-filter / vulnerability-prioritization path. Use when a scanner flags a CVE that analysis confirms is not exploitable in your deployment, and a machine-readable `not_affected` assertion is needed to suppress false positives without discarding the finding from the audit trail.