This article follows the official documentation. We haven’t tested this tool for a hands-on review.
When a coding agent can run shell commands in a code repository, it can use Trivy to check dependencies, secrets, and infrastructure configuration before it proposes a change. Trivy is a security scanner that reads files and reports known package vulnerabilities and exposed credentials. It also reports unsafe configuration. A finding is a reported concern for a developer to review; it does not by itself prove that vulnerable code runs or that a secret was exposed.
For a local repository scan, the agent runs Trivy from the project directory and reads the results. Trivy reads the project files and does not need to change them. It may access the network to retrieve vulnerability data. The example below asks for JSON output so the agent can inspect findings without relying on terminal table formatting. The commands assume trivy is installed and available on the shell’s PATH.
Install Trivy
The installation page lists the official install options. On macOS and Linux with Homebrew, run:
brew install trivy
In March 2026, an attacker used stolen credentials to publish a malicious Trivy release and malicious container images. The Trivy security advisory lists the affected versions and says the official Homebrew formula was not affected, because it builds Trivy from source. If you download a release binary or image, the signature verification guide shows how to check it.
Scan a repository
Run this command from the repository root:
trivy fs --scanners vuln,secret,misconfig --severity HIGH,CRITICAL --format json .
fs tells Trivy to scan files in the current directory. The --scanners option selects checks for vulnerabilities, exposed secrets, and configuration problems. Without it, trivy fs checks only vulnerabilities and secrets. --severity limits reported findings to high and critical severity, while --format json requests machine-readable output. Trivy also supports several output formats, as described in its reporting documentation. These include table and SARIF, as well as template and SBOM.
The command prints JSON to standard output, the stream that normally appears in the terminal, and does not save the results to a file. Add --output results.json if you want a file instead. The agent can read the JSON and summarize which files or dependencies need attention. This article provides documentation-based usage, not results from an installed or tested Trivy run.
A coding agent could receive a prompt like this:
Run the documented Trivy filesystem scan from the repository root. Summarize high- and critical-severity findings, cite the affected file or package shown in the output, and recommend a next step for each. Do not edit files or suppress findings.
This keeps the first pass read-only from the project’s perspective. If the agent proposes a code change afterward, the developer can review that change and rerun the scan.
Understand the network and credentials
The example scans local files and does not require a Trivy account login or registry credentials. Trivy needs vulnerability data for package checks. The database documentation says Trivy downloads and updates these databases automatically when it needs them. The scan itself does not send a request to a code-hosting service to make changes to the repository.
For a private container image, access depends on the authentication setup of its registry, the service that stores the image. The private registry guide recommends trivy registry login, which stores the credentials for one registry. It warns that credentials passed through environment variables or flags are tried on every registry Trivy contacts during a scan. Do not paste secrets into the agent prompt.
Read findings with care
An agent can use a severity filter to focus its report, but the filter does not show whether an attacker can exploit an issue or whether the affected code runs. The agent should preserve Trivy’s finding details and describe uncertainty rather than treating every result as a confirmed vulnerability in running code. Trivy’s filtering options also support filtering by status and suppressing findings by ID or policy. Trivy reads a .trivyignore file in the current directory by default, so findings listed there do not appear in the report. Suppression changes what appears in reports, so an agent should not add ignore rules without approval.
An image scan inspects packages in an image, while a configuration scan checks infrastructure files. A Dockerfile in the repository is one of those files, so the misconfig scanner in the command above checks it. One example is a missing USER instruction, which sets the user the container runs as. The container image guide says the same check on a built image is turned off by default. You turn it on with --image-config-scanners misconfig.
Trivy can also generate software bills of materials, or SBOMs, in the CycloneDX and SPDX formats. An SBOM is an inventory of the packages in a project or image. Trivy’s SBOM output is useful alongside a scan, but organizations that need specific SBOM metadata should check that the generated format meets their requirements.