Trivy: One Scanner for Containers, Code, Kubernetes, and Cloud Config

What Trivy solves and who it is for

Trivy addresses a practical pain: security scanning has historically meant running several different tools, one for container images, another for IaC templates, another for secrets, and yet another for SBOM generation. Trivy collapses those into a single binary with a uniform command syntax. The README defines two axes: targets (what you scan) and scanners (what you look for). Targets include container images, filesystems, git repositories (remote), virtual machine images, and Kubernetes. Scanners cover OS packages and dependencies (SBOM), known CVEs, IaC misconfigurations, secrets, and software licenses. The intended user is an engineer or platform team that wants a single tool to plug into CI pipelines, local development, and cluster auditing without learning five different CLIs. The project is maintained by Aqua Security, which also sells a commercial product that builds on Trivy, so the open-source tool is positioned as a foundation rather than a complete enterprise offering.

The scanner and target matrix in practice

The core design is a matrix: you pick a target and optionally restrict which scanners run. The general command is `trivy <target> [--scanners <scanner1,scanner2>] <subject>`. For example, `trivy image python:3.4-alpine` scans a container image with default scanners, and `trivy fs --scanners vuln,secret,misconfig myproject/` scans a filesystem for vulnerabilities, secrets, and misconfigurations in one pass. The `k8s` target accepts a `--report summary` flag, as in `trivy k8s --report summary cluster`, which produces a summarized view of cluster issues. This matrix means you can combine scanners that would normally require separate tools, but it also means the scanner logic must share data structures and reporting formats. The documentation does not state whether all scanner combinations are supported on every target; the examples show different scanner sets for images versus filesystems, implying that some combinations are target-specific. You should check the Scanning Coverage page before assuming a given scanner works on a given target.

Getting Trivy running: commands and installation

Installation is straightforward and multi-channel. The README lists `brew install trivy` for macOS, `docker run aquasec/trivy` for containerized use, and direct binary downloads from the GitHub releases page. The full installation options live in the documentation. Once installed, you run it as a single binary with no daemon or server component, which keeps CI integration simple. For example, to scan a local project directory, you would run `trivy fs --scanners vuln,secret,misconfig myproject/`. For Kubernetes, `trivy k8s --report summary cluster` gives a high-level view. There are also canary builds generated on every push to main, available as Docker images and binaries, but the README warns they might have critical bugs and are not for production. That warning is a useful signal: the main branch moves fast, and you should pin a stable release version in your pipelines rather than tracking latest.

Where Trivy falls short: breadth versus depth

The most obvious limitation is that Trivy tries to do everything, which means it cannot match the depth of specialized tools in any single domain. For IaC misconfigurations, a dedicated policy engine like Checkov or Open Policy Agent (the README links to Rego, the policy language) offers more granular, customizable rules. For secrets, a tool like gitleaks or trufflehog is designed specifically to minimize false positives and catch context-aware leaks. Trivy's secret scanner is a generalist, and the README does not claim otherwise. Another limitation is the Kubernetes target: the `--report summary` flag suggests a high-level output, but the README's result section for `trivy k8s` is empty, so you cannot see what the summary actually includes. The documentation likely covers it, but the absence of an example is a gap. Finally, the commercial Aqua product is positioned as 'even more enhanced capabilities,' which implies the open-source version has deliberate feature boundaries, though the README does not enumerate them.

Alternatives and how they differ in approach

The most direct alternative is Grype from Anchore, which also scans container images and filesystems for vulnerabilities and has SBOM support. The key difference is that Grype focuses on vulnerability scanning and integrates with Syft for SBOM, whereas Trivy bundles misconfigurations, secrets, and Kubernetes into the same binary. If you only need CVE scanning for images, Grype is a lighter choice. For IaC misconfigurations, Checkov (by Bridgecrew) uses a policy-as-code approach with hundreds of built-in policies and supports Terraform, CloudFormation, and Kubernetes manifests. Trivy does have misconfiguration scanning, but it is not the primary focus. For secrets, gitleaks is a dedicated regex-based scanner that runs as a pre-commit hook or in CI, while Trivy's secret scanner is one of several. The choice depends on whether you value a single tool with moderate coverage or multiple specialized tools with deeper coverage per domain.

Maintenance, releases, and license considerations

Trivy is actively maintained, with three releases in the last two months as of the data provided: v0.74.0 on 2026-08-14, v0.73.0 on 2026-08-03, and v0.72.0 on 2026-06-30. This cadence suggests frequent updates, which is typical for a security scanner that must track new CVEs and package formats. The project is licensed under Apache-2.0, which is permissive for commercial use, but note that the README promotes Aqua's commercial product, so there is a clear commercial layer above the open-source core. The upgrade cost is moderate: because Trivy is a single binary, upgrading is a matter of replacing the binary or pulling a new Docker image. However, the scan database (the vulnerability data) is separate and updates continuously, so you need to ensure your CI environment can fetch the latest database, which might be a network dependency. The canary builds indicate a fast-moving main branch, so pinning to a stable release tag is advisable for production.

What to verify before adopting Trivy

Before committing to Trivy, verify three things from the documentation. First, the Scanning Coverage page lists supported programming languages, OSes, and platforms; if your stack uses an uncommon language or a niche package manager, Trivy may not detect its dependencies. Second, test the Kubernetes target against your cluster, because the `k8s` command requires appropriate RBAC permissions to list resources, and the summary output format may not suit your reporting needs. Third, check the ecosystem integrations, such as the GitHub Action, Kubernetes operator, and VS Code plugin, to see if they meet your workflow. The README does not specify the exact behavior of the `k8s` summary, so you should run it on a test cluster to see what it produces. Also, decide whether the commercial Aqua layer is a future requirement, because migrating from the open-source tool to the commercial product may involve additional setup.

Editorial conclusion

Adopt Trivy if you need one tool that spans container images, filesystems, git repos, VM images, and Kubernetes clusters, and if you want a single CLI for vulnerabilities, secrets, misconfigurations, and SBOM. Skip it if you require deep, specialized scanning in one domain, such as a dedicated IaC policy engine or a commercial-grade secret detector, because Trivy's breadth means each scanner is a generalist. Before production use, verify the scanning coverage page for your exact OS, language, and package manager, and test the Kubernetes summary output against your cluster's RBAC, since the `k8s` command depends on cluster access permissions. Also confirm the license implications of running Aqua's commercial layer if you later move beyond the open-source core.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes