Trivy: one scanner for CVEs, misconfigurations, secrets and SBOMs

What Trivy scans, and the question it answers

Trivy splits its work into two concepts the README states plainly: scanners, which are the kinds of problems it looks for, and targets, which are the places it looks. The scanners cover OS packages and software dependencies (SBOM), known vulnerabilities (CVEs), IaC issues and misconfigurations, sensitive information and secrets, and software licenses. The targets are container images, filesystems, remote Git repositories, virtual machine images and Kubernetes.

That structure is the whole pitch. Most teams end up with four or five separate tools for those jobs, each with its own output format and its own ignore syntax. Trivy answers a narrower question than a code analysis platform does: what is inside this artifact, and which of those things have known problems attached to them. It does not reason about whether your application logic is correct, and it does not attempt to prove exploitability. If you want the inventory, this is a fast way to get it. If you want a verdict on your code, this is the wrong category of tool.

How the scanners and the vulnerability database fit together

Trivy is written in Go and ships as a single binary. The go.mod file shows the dependency graph that does the real work: trivy-db and trivy-java-db supply the vulnerability data, and trivy-checks supplies the misconfiguration rules. Those are separate modules with their own release cadence, which is why a Trivy binary version and a database version are different things. The database is fetched rather than compiled in, so the accuracy of a scan depends on when the database was last refreshed, not on which release of the CLI you installed.

Language-specific version comparison is handled by dedicated libraries rather than string matching. The dependency list includes go-version, go-npm-version, go-pep440-version and go-gem-version, which means npm, Python, Ruby and generic semver ranges each get parsed with their own rules. This matters more than it sounds: a scanner that compares version strings naively will produce false positives on ranges and pre-release tags. The presence of these separate parsers is the clearest signal in the repository that range handling was treated as a first-class problem.

Cloud and registry access is also in the dependency graph, with SDKs for AWS (ECR, EC2, S3), Azure container registry and Google Cloud credential helpers. That is how the same binary can pull an image from a private registry without a separate authentication tool.

Installing Trivy and scanning your first Docker image

The README lists the common distribution channels and points to the installation page for the full set. On macOS or Linux with Homebrew, one command is enough. The Docker image is published as aquasec/trivy, and the repository's own Dockerfile is Alpine-based, installs ca-certificates and git, and sets the entrypoint to trivy, so you can pass subcommands directly.

brew install trivy

If you would rather not install anything on the host, run the container instead. The entrypoint is already trivy, so the arguments after the image name are the normal CLI arguments.

docker run aquasec/trivy

The general form the README gives is a target, an optional scanner list, and a subject. Scanning a filesystem with several scanners at once looks like this:

trivy fs --scanners vuln,secret,misconfig myproject/

For a cluster, the README shows a summary report:

trivy k8s --report summary cluster

What you should see is a table of findings grouped by the artifact they belong to, with a severity column. The first run downloads the vulnerability database, so it takes longer than subsequent runs. Note that the README does not document an offline mode or a manual database path here; for air-gapped environments you will need the documentation site, not the README.

Where Trivy stops being the right tool

The scanner finds known CVEs in OS packages and dependencies. It does not find logic flaws, authentication mistakes or design problems in code you wrote yourself. A project with no third-party dependencies and no container image will produce a very short report, and that short report is not evidence that the code is safe.

There is a second, quieter limitation. Because the vulnerability data lives in external databases, the tool's output is only as current as the last database sync, and a scan that cannot reach the database will not tell you what you are missing. The README does not document rollback behaviour or a signed-database verification step; the repository does contain a .vex/ directory and a SECURITY.md, and the README links to sigstore, but neither the README nor the file list explains how those are applied at scan time. If your compliance process requires a documented chain from finding to verified fix, that chain is not described in the README.

The canary builds deserve a mention because the README is unusually direct about them: images and binaries are generated with every push to main, and the README says they might have critical bugs and are not recommended for production. That is a sensible warning, and it also means the main branch is not a stable target for pinned installations.

Trivy compared with SonarQube

The two tools get compared often, and the comparison mostly dissolves once you look at what each one reads. SonarQube analyzes source code: it parses your functions, tracks data flow, and reports on code smells, bugs and security hotspots in the code you wrote. Trivy analyzes artifacts: it opens a container image or a lockfile and matches what it finds against a database of known vulnerable versions.

So the overlap is thin. If you want to know that a dependency pinned in package.json has a published CVE, Trivy answers that and SonarQube generally does not. If you want to know that a request parameter reaches a SQL string without sanitization, that is SonarQube's territory and Trivy will not see it, because the flaw is in your code rather than in a version number. Teams that need both run both; the outputs are not substitutes. The practical difference in operation is that Trivy is a single binary you invoke in CI and SonarQube is a server you host and maintain.

Licence, releases and what upgrades cost you

Trivy is Apache-2.0, and the repository carries both a LICENSE and a NOTICE file, which is the standard Apache-2.0 arrangement. Apache-2.0 permits commercial use and modification and includes an explicit patent grant. The NOTICE file exists to carry attribution, and if you redistribute a modified Trivy you should read it rather than assume it is decorative. This is not legal advice; if redistribution is part of your plan, have counsel read the NOTICE.

The release cadence visible here is roughly monthly: v0.72.0 on 2026-06-30, v0.73.0 on 2026-08-03, and v0.74.0 on 2026-08-14. The last push to the default branch was on 2026-08-14. That is a steady rhythm, and it also sets your upgrade cost: a monthly CLI release plus a continuously refreshed vulnerability database. The database refresh is the part you cannot skip, because skipping it is the same as scanning against an old world. The README also notes that Trivy is integrated with GitHub Actions, a Kubernetes operator and a VS Code extension, so pinning those integrations is a separate version decision from pinning the CLI.

Who should put Trivy in the pipeline

The fit is a team that builds container images or ships dependency-heavy applications and wants a scanner it can run in CI without standing up a server. The CLI form makes that straightforward, and the ecosystem integrations listed in the README mean you do not have to write the CI glue yourself for GitHub Actions or Kubernetes.

The mismatch is a team that wants a managed product. Trivy is a scanner, not a platform: there is no dashboard in this repository, no ticket workflow, and no remediation tracking. The README is explicit that Aqua builds a commercial offering on top of Trivy and links to a comparison table for Trivy users, so the boundary between the open source scanner and the paid product is drawn deliberately and is worth reading before you promise a feature to someone.

A second mismatch is any environment where the scanner cannot reach the vulnerability database. Nothing in the README describes how to operate without it.

Editorial conclusion

Adopt Trivy if you want one CLI that covers container images, filesystems, Git repositories, VM images and Kubernetes, and you are willing to run it yourself. Do not adopt it if you expect a managed dashboard with ticketing, or if you need deep static analysis of your own source code rather than dependency and OS package matching. Before rolling it out, verify one thing first: run trivy image against a single image you already know the contents of and confirm the vulnerability list matches your expectations, because the results come from the external trivy-db and trivy-java-db feeds and a stale or unreachable database will silently change what you see.

Frequently asked questions

Official sources

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