# Trivy: one binary, five targets, a scanner list

> A security scanner whose whole design is two nouns, targets and scanners, so the same binary scans an image, a working tree, a remote repository, a VM image or a cluster. The cost of that design is that what you get depends on a scanner list you have to think about.

**aquasecurity/trivy** — Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more

- Repository: https://github.com/aquasecurity/trivy
- Website: https://trivy.dev
- Stars: 38,073 · Forks: 711
- Language: Go
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/aquasecurity-trivy

## The target comes first, the scanner list comes second

Everything about Trivy's shape follows from two nouns. It has targets, which are places it can look, and scanners, which are the things it looks for. The targets are a container image, a filesystem, a remote git repository, a virtual machine image, and Kubernetes. The scanners are OS packages and software dependencies in use, which is the SBOM; known vulnerabilities; infrastructure as code issues and misconfigurations; sensitive information and secrets; and software licenses. That vocabulary is the entire user interface, because the general usage line is one pattern:

```bash
trivy <target> [--scanners <scanner1,scanner2>] <subject>
```

So a Trivy invocation always answers three questions: what kind of place, what kind of problem, and which thing in that place. The consequence for a reader is that the tool is not a single scanner with a single meaning. Two invocations against the same repository can return different finding sets for no other reason than the scanner list, which is why a CI job that grew from `trivy image` to `trivy fs` is a change in coverage and not just a change of command.

## Three commands cover image, filesystem and cluster

The examples given in the project are short enough to memorise, which is the point of a scanner with one entry point. Against a container image, naming the image is the whole command:

```bash
trivy image python:3.4-alpine
```

Against a working tree, the scanner list is spelled out:

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

Against a live cluster, the subject is `cluster` and the output shape is chosen explicitly:

```bash
trivy k8s --report summary cluster
```

Read those three together and the interface stops being abstract. The filesystem example names three scanners, the image example names none, and the project text does not state which scanners run by default, so a reader assembling a first pipeline has to decide rather than inherit. The `k8s` example is the other half of the lesson: a subject can be a live cluster rather than an artifact, and `--report` is what decides whether you get a table a human reads or something a machine consumes. Everything else, from remote git repositories to VM images, follows the same pattern of target, scanners, subject.

## The container image is Alpine, git and one copied binary

There are three documented ways to get the tool, and they are not equivalent in what they let you do later. Homebrew installs it as `brew install trivy`. The container route is `docker run aquasec/trivy`. The third is a binary from the releases page. The container image is worth looking at, because its Dockerfile is six lines and tells you what the container route costs. It starts from `alpine:3.24.2`, adds `ca-certificates` and `git`, copies the compiled binary to `/usr/local/bin/trivy` using a `TARGETPLATFORM` build argument, copies `contrib/*.tpl` alongside it, and sets `trivy` as the entrypoint. `git` is there for the remote git repository target, which means a container invocation against a git URL needs that image rather than a scratch base. The `contrib` templates are copied too, so a run that expects them should not be built from a different base.

## Canary rebuilds on every push, and the README rules them out of production

There is a second channel of builds, and the project is unusually direct about its limits. Canary images and binaries are generated with every push to the main branch, published to Docker Hub, the GitHub container registry and ECR under the `canary` tag, and the warning is explicit: canary builds might have critical bugs, so they are not recommended for use in production. The tree backs this up with a separate `goreleaser-canary.yml` and a `Dockerfile.canary` next to the release ones, so the canary path is a parallel pipeline rather than a flag. What it is good for is seeing what a change does before it is tagged, since a canary build is the closest thing to a preview. What it is bad for is anything reproducible: the tag is rewritten on every push, so two runs of `canary` an hour apart are two different programs. Pin a release tag if you want the same scanner twice.

## Policy and advisory content arrive as separate Go modules

The scanners do not live in this tree. `go.mod` declares the module as `github.com/aquasecurity/trivy` on a Go 1.27.0 toolchain, and among the direct requirements are four sibling modules with their own version lines: `trivy-checks`, `trivy-db`, `trivy-java-db` and `trivy-kubernetes`, plus `cyclonedx-go` for SBOM output, `iamgo` for cloud identity work, and the AWS and Azure SDKs with specific services pinned for EC2, ECR and S3 on one side and container registries on the other. Three trivy-namespaced data modules alongside the main one tells you the finding content is versioned separately from the scanner that reports it. The repository agrees: `examples/` holds `ignore-policies/`, `module/` and `trivy-conf/`, so suppressing or extending a finding is a data and configuration operation, and `.vex/` is there for exploitability data. The practical consequence is that bumping Trivy can move the policy content and the scanner together, which is worth reading before a version bump lands in CI.

## The commercial product is a layer above, and the README says so

The project page is candid about the boundary. Trivy is an Aqua Security open source project, released under Apache-2.0, and the README carries a section pointing at Aqua, which builds on top of Trivy to provide a wider security management offering, with a comparison table aimed specifically at people arriving from Trivy and a form to request a demo. That matters when you read about Trivy capabilities elsewhere: the check you want is whether a feature lives in this repository or in the layer above it, and the project's own answer to that question is a comparison page rather than a line in the README. The licensing side is simple to state. The repository carries a LICENSE file and a NOTICE file, which is what a Go project with this many vendored dependencies tends to carry, and go.mod shows the Azure, AWS and CycloneDX code involved. If provenance of a dependency matters to you, the NOTICE file is the place to look.

## Every documentation link points at /docs/latest/, so a bookmark rots

Look at where the installation page, the ecosystem page and the scanning coverage page live. All three are under `trivy.dev/docs/latest/`, and so is the documentation site link. The consequence is small and permanent: a URL you saved in a runbook is always serving whatever the current release says, and the content under it changes without the link changing. There is a second version signal next to it. The recent tags run v0.72.0 on 2026-06-30, v0.73.0 on 2026-08-03 and v0.74.0 on 2026-08-14, which is a 0.x line turning over minor versions every few weeks, and the last push to the main branch was on 2026-09-25. Reading a flag name in current docs and then pinning an older binary is the failure this produces. The repository keeps a CHANGELOG.md at the root, so the check before a version bump is a diff of that file between your tag and the target.

## Conclusion

Trivy fits a pipeline that needs one tool across images, source trees and clusters, and where a findings file that CI can parse is enough. It does not fit a team that wants one scan to mean the same thing everywhere without deciding which scanners run, because that decision is per invocation. Before you pin a version, read CHANGELOG.md at the root between your current tag and the one you want, and remember the last push was on 2026-09-25 while the newest release is v0.74.0 from 2026-08-14.

## FAQ

### What is a Trivy?

Trivy is a security scanner built around two ideas, targets and scanners. Targets are a container image, a filesystem, a remote git repository, a virtual machine image or Kubernetes, and scanners are OS packages and dependencies, known vulnerabilities, IaC misconfigurations, secrets and software licenses.

### How to use trivy?

Every invocation follows one pattern, trivy <target> [--scanners <scanner1,scanner2>] <subject>. The documented examples are trivy image python:3.4-alpine, trivy fs --scanners vuln,secret,misconfig myproject/ and trivy k8s --report summary cluster.

### How to use trivy to scan a docker image?

Use the image target and name the image, for example trivy image python:3.4-alpine. You can also run the published container directly with docker run aquasec/trivy, whose image is Alpine with ca-certificates and git added and the trivy binary as its entrypoint.

### how to install trivy

Three routes are named: brew install trivy, docker run aquasec/trivy, or downloading the binary from the latest release. The project also lists integrations for GitHub Actions, a Kubernetes operator and a VS Code plugin, each in its own repository.

### Is Trivy safe to use?

The project does not address that question directly. What it does say is that canary builds, which are generated on every push to the main branch, might have critical bugs and are not recommended for use in production, so the release tags are the ones to use.

## Sources

- [Official documentation](https://trivy.dev)
- [Official README](https://github.com/aquasecurity/trivy#readme)
- [Project repository](https://github.com/aquasecurity/trivy)
- [Release notes](https://github.com/aquasecurity/trivy/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aquasecurity-trivy
