Trivy Vulnerability Scanner Cheat Sheet

Updated 2026-05-22

Next Topic: Velero Kubernetes Backup and Disaster Recovery Cheat Sheet

🧠Study flashcards on this topic96 cards · spaced repetition→

Trivy is an open-source, all-in-one security scanner developed and maintained by Aqua Security, designed to find vulnerabilities, misconfigurations, secrets, and supply-chain risks across containers, filesystems, Kubernetes clusters, IaC files, and cloud accounts. Its key differentiator is breadth — a single binary replaces multiple specialized tools by combining CVE scanning, IaC misconfiguration detection, secret detection, SBOM generation, and license compliance in one pass. The mental model to keep in mind is that Trivy always works along two axes: a target (what you scan) and a scanner (what type of issue you look for) — mixing and matching them unlocks its full power.

What This Cheat Sheet Covers

This topic spans 16 focused tables and 113 indexed concepts, 96 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Scan TargetsTable 2: Scanners (What Trivy Looks For)Table 3: Core CLI FlagsTable 4: Vulnerability Database ManagementTable 5: Filtering and SuppressionTable 6: Output Formats and ReportingTable 7: Misconfiguration Scanning (IaC Security)Table 8: Secret ScanningTable 9: SBOM Generation and Supply-Chain ScanningTable 10: Private Registry AuthenticationTable 11: Client/Server ModeTable 12: Trivy Operator (Kubernetes-Native Continuous Scanning)Table 13: CI/CD IntegrationTable 14: Configuration File (trivy.yaml)Table 15: Trivy vs Alternatives — Key DistinctionsTable 16: Common Pitfalls and False Positives

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Scan Targets

Every Trivy invocation begins with a target subcommand. Understanding what each target scans — and which scanners it activates by default — prevents missed coverage and unexpected false negatives.

Command	Example	Description
trivy image	`trivy image nginx:1.27`	• Scans a container image from a registry, local Docker daemon, tarball, or OCI archive for vulnerabilities, misconfigurations, and secrets • Most common entry point for container security
trivy fs	`trivy fs ./myproject`	Scans a local filesystem or directory for vulnerabilities in dependency files, misconfigurations, and secrets.
trivy repo	`trivy repo https://github.com/org/repo`	Clones and scans a remote Git repository for vulnerabilities, misconfigurations, and secrets.
trivy k8s	`trivy k8s --report summary cluster`	Scans a live Kubernetes cluster (current kubeconfig context), checking running workload images and K8s resource definitions.
trivy config	`trivy config ./terraform/`	Scans IaC configuration files only — Dockerfile, Kubernetes YAML, Terraform, CloudFormation, Helm, Ansible, etc.
trivy sbom	`trivy sbom ./bom.cdx.json`	Scans an existing SBOM file (CycloneDX, SPDX) for vulnerabilities, avoiding re-analysis of the original artifact.
trivy rootfs	`trivy rootfs /path/to/rootfs`	Scans an unpacked root filesystem directory, useful for embedded systems and VM image analysis.
trivy aws	`trivy aws --service s3,ec2`	Scans a live AWS account for misconfigurations across services such as S3, EC2, IAM, and RDS.
trivy vm	`trivy vm disk.vmdk`	Scans a virtual machine image (VMDK, OVA, VHD) for OS package vulnerabilities.

Table 2: Scanners (What Trivy Looks For)

Scanners are the analysis engines that run on a target. They can be combined with --scanners or disabled individually; knowing which ones run by default avoids surprises in CI output.

Scanner	Example	Description
vuln (vulnerability scanner)	`trivy image --scanners vuln nginx:latest`	• Detects known CVEs in OS packages and language-specific libraries by comparing installed versions against the `trivy-db` vulnerability database • Enabled by default

The rest of this section is part of the full cheat sheet

Table 3: Core CLI Flags

These flags appear in nearly every real-world Trivy invocation. Knowing their defaults and interactions is essential for writing useful CI pipeline steps.

Flag	Example	Description
--severity	`trivy image --severity HIGH,CRITICAL nginx`	Filters output to show only findings at or above the specified severity levels (UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL). Applies to all scanner types.

The rest of this section is part of the full cheat sheet

Table 4: Vulnerability Database Management

Trivy maintains three separate databases pulled as OCI artifacts. Understanding update cadence and cache management is critical for CI pipeline speed, air-gapped environments, and reproducible scans.

Component	Example	Description
trivy-db (vulnerability DB)	`trivy image --download-db-only`	• Primary CVE database pulled from `ghcr.io/aquasecurity/trivy-db`. Updated every 6 hours • Trivy auto-refreshes it before each scan unless `--skip-db-update` is set

The rest of this section is part of the full cheat sheet

Table 1: Scan Targets

Command	Example	Description
trivy image	`trivy image nginx:1.27`	• Scans a container image from a registry, local Docker daemon, tarball, or OCI archive for vulnerabilities, misconfigurations, and secrets • Most common entry point for container security
trivy fs	`trivy fs ./myproject`	Scans a local filesystem or directory for vulnerabilities in dependency files, misconfigurations, and secrets.
trivy repo	`trivy repo https://github.com/org/repo`	Clones and scans a remote Git repository for vulnerabilities, misconfigurations, and secrets.
trivy k8s	`trivy k8s --report summary cluster`	Scans a live Kubernetes cluster (current kubeconfig context), checking running workload images and K8s resource definitions.
trivy config	`trivy config ./terraform/`	Scans IaC configuration files only — Dockerfile, Kubernetes YAML, Terraform, CloudFormation, Helm, Ansible, etc.
trivy sbom	`trivy sbom ./bom.cdx.json`	Scans an existing SBOM file (CycloneDX, SPDX) for vulnerabilities, avoiding re-analysis of the original artifact.
trivy rootfs	`trivy rootfs /path/to/rootfs`	Scans an unpacked root filesystem directory, useful for embedded systems and VM image analysis.
trivy aws	`trivy aws --service s3,ec2`	Scans a live AWS account for misconfigurations across services such as S3, EC2, IAM, and RDS.
trivy vm	`trivy vm disk.vmdk`	Scans a virtual machine image (VMDK, OVA, VHD) for OS package vulnerabilities.

Table 2: Scanners (What Trivy Looks For)

Scanners are the analysis engines that run on a target. They can be combined with --scanners or disabled individually; knowing which ones run by default avoids surprises in CI output.

Scanner	Example	Description
vuln (vulnerability scanner)	`trivy image --scanners vuln nginx:latest`	• Detects known CVEs in OS packages and language-specific libraries by comparing installed versions against the `trivy-db` vulnerability database • Enabled by default

Table 3: Core CLI Flags

These flags appear in nearly every real-world Trivy invocation. Knowing their defaults and interactions is essential for writing useful CI pipeline steps.

Flag	Example	Description
--severity	`trivy image --severity HIGH,CRITICAL nginx`	Filters output to show only findings at or above the specified severity levels (UNKNOWN, LOW, MEDIUM, HIGH, CRITICAL). Applies to all scanner types.

Table 4: Vulnerability Database Management

Trivy maintains three separate databases pulled as OCI artifacts. Understanding update cadence and cache management is critical for CI pipeline speed, air-gapped environments, and reproducible scans.

Component	Example	Description
trivy-db (vulnerability DB)	`trivy image --download-db-only`	• Primary CVE database pulled from `ghcr.io/aquasecurity/trivy-db`. Updated every 6 hours • Trivy auto-refreshes it before each scan unless `--skip-db-update` is set