One CLI scans five kinds of target
Trivy scans container images, filesystems, remote Git repositories, virtual machine images, and Kubernetes. Its scanners look for known vulnerabilities, exposed secrets, infrastructure configuration problems, licenses, and the components needed for a software bill of materials. A developer can check a project directory, then use the same command family in CI and against a deployment target.
The breadth comes with real size. Our commit dc3c56e checkout contained 3,310 files, about 277,035 lines of source, and 22 CI workflow files. It had a Dockerfile and no top-level tests directory, while Go tests were distributed across packages. Trivy supports many operating systems, languages, and platforms, but the README promises popular choices rather than universal coverage and sends readers to a detailed matrix.
Vulnerability results need policy and review
A scan can identify installed packages and match them with published CVEs. That is evidence about known issues, not proof that a particular application is exploitable. Teams still need to set severity thresholds, decide whether unfixed findings block a release, account for vendor status, and record temporary exceptions. Trivy produces the report; it cannot make the risk decision for the service owner.
Secret, configuration, and license results need the same care. Open work in August 2026 includes fixes for empty parser inputs, SPDX NOASSERTION handling, and CSAF relationship processing. Those examples show why scanner upgrades deserve regression checks against an organization's own artifacts. A green scan also cannot establish that an unsupported format contains no flaw.
What happened when we ran it
Our sandbox installed 1,003 Go packages in 135 seconds. The build succeeded in 210 seconds. We used commit dc3c56e in an unprivileged golang:1.24-bookworm container with 3 CPUs, 8 GB of RAM, and no secrets. The checkout itself was 94.4 MB before those dependencies were installed.
The test command ran for 442 seconds and exited with code 1. Go reported 213 packages passing and 3 failing out of 216. The provided log tail lists passing utility packages for HTTP, I/O, JSON, operating systems, and paths, plus several packages with no test files, then ends at the overall FAIL. It does not name the three failures or show their assertions.
We cannot say whether those failures require network access, fixture data, different system packages, or a code fix. The exact finding is that commit dc3c56e built but did not pass its full suite in our fresh environment. Before shipping a custom binary or embedding the source as a Go library, capture the complete output and reproduce the three failed packages.
Stable binaries avoid the 210-second source build
Most users do not need to build the repository. The README lists Homebrew, an aquasec/trivy container, and downloadable release binaries. GitHub Actions, a Kubernetes operator, and a VS Code extension cover common integrations. Stable release v0.74.0 was published on August 14, 2026, one week before GitHub recorded the repository's latest push.
Canary binaries and images are generated for every main-branch push. The project warns that these may contain critical bugs and should not be used in production. That matters for a security gate, where a scanner crash, parser regression, or changed result format can halt delivery or let a bad artifact through. Pin a stable version and schedule upgrades instead of following canary.
Current advisory data is part of every scan
A vulnerability scan needs current advisory data as well as the executable. Container work also needs image-layer access and private-registry credentials where applicable. Kubernetes scanning needs cluster authorization. CI operators should cache updates deliberately so parallel jobs do not all repeat the same download or fail on an avoidable network dependency.
The pipeline also needs explicit failure rules. trivy fs --scanners vuln,secret,misconfig examines a project directory, while image and Kubernetes targets have their own modes. Select checks the team can act on, preserve a report, and test the chosen exit-code policy. A command that prints findings but always exits successfully gives information without enforcing a release decision.
SBOM inventory is evidence, not a security verdict
Trivy can list operating-system packages and application dependencies for an SBOM, then scan those components for known vulnerabilities. This works well when another system handles storage, signing, attestations, or policy. Current CycloneDX cryptographic-asset work is carefully limited to discovery rather than judging whether a key is used or secure.
An inventory tells you what the scanner recognized and where it appeared. It may miss an unsupported package format or classify incomplete metadata conservatively. Keep the generated SBOM as evidence, compare it across releases, and review exceptions. Do not turn a green report into a claim that the artifact has no security flaws.
August activity supports a pinned adoption
GitHub showed 37,640 stars, 259 combined issues and pull requests, and a last push on August 21, 2026. Release v0.74.0 arrived on August 14. The open count includes contributions and feature work, so it is not a bug count. The 22 workflow files and current parser fixes show active engineering on a large scanning surface.
Trivy is a practical first scanner because it covers several jobs without forcing five separate CLIs into the build. Our 3 failed packages keep this measured commit below a clean bill of health. Use the stable distribution, pin its data and output assumptions where possible, and investigate source-level failures before customization. Grype or OSV-Scanner is easier to reason about when vulnerability matching is the only requirement.