Grype for coding agents

A coding agent with shell access can run Grype to compare a repository’s software packages, including libraries and other dependencies, with a database of known vulnerabilities. Grype reports matches; it does not inspect source code for general programming flaws or secrets.

Grype is an open-source command-line scanner from Anchore that checks software packages for known vulnerabilities. An agent can run Grype on the project’s machine to check its dependencies, then use the results to flag items for human review or a separate code change. Grype also scans a software bill of materials (SBOM), a file that lists the components in a software project. Anchore’s Grype documentation covers installation, and the CLI reference lists every flag, including the output formats and the severity-based exit code.

Install and run Grype

Anchore’s official installer script works on Linux and macOS:

curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin
grype version

The first command installs Grype into /usr/local/bin, and the second confirms that your shell can run it. The installation page lists Homebrew as a community build, installed with brew tap anchore/grype and then brew install grype. A standard scan requires no account or login. Grype needs network access to download its vulnerability database and to pull container images. After the first download, it can scan offline until you update the database. Grype scans on the machine where the agent runs the command.

From the repository root, run:

grype dir:.

The dir:. target tells Grype to inspect the current directory for package information. Grype uses that inventory to look for known vulnerabilities. The default output is a readable table. To save a report in JSON, a structured format, for later review, run:

grype dir:. --output json > grype-report.json

This command writes the report to grype-report.json in the current directory. The agent should treat the report as generated data and avoid committing it unless the repository’s conventions call for that. Grype’s documented CLI options also include --fail-on, which sets a severity threshold for a nonzero exit status. For example:

grype dir:. --fail-on high

The CLI reference says this sets the exit code to 2 when Grype finds a vulnerability at or above the chosen severity. The allowed values run from negligible up to critical. Use the threshold your project expects; a failing status is a signal for review, not a fix.

Use findings in an agent task

Ask an agent to scan the repository after you change dependencies and summarize the reported vulnerabilities. Leave decisions about how to fix them to the developer. The agent can run the scan, review the table or JSON report, and match findings to the project’s dependency files. It should not claim that a reported package is exploitable in the project without checking how the code uses it.

For example, an agent prompt could say:

Run grype dir:. from the repository root. Summarize any findings with their package, severity, and vulnerability identifier. Do not edit files or update dependencies. If there are no findings, say that Grype reported no matches.

This keeps the task read-only. The agent runs local commands and receives results in its shell. When Grype starts, it checks online for a newer vulnerability database and downloads it if one is available. Anchore’s getting started guide says Grype does not send scan data to external services. If the JSON report is large, have the agent save it and summarize relevant entries instead of pasting the full file into the conversation.

Understand what a clean scan means

Grype matches known vulnerabilities to the packages it can identify. A scan with no findings means it found no matching vulnerabilities in that inventory and database. It does not prove that the code is secure, and it does not replace source-code analysis, secret scanning, or review of runtime behavior.

Results also depend on which packages Grype identifies and how it matches them to entries in its vulnerability database. The database matters too. According to the database guide, Grype fails a scan when its database is more than five days old, unless you change that check in the configuration. grype db update downloads a new database, and grype db check only reports whether one is available. When comparing scans, use the same source for the package inventory. Treat severity thresholds as project policy, not as a universal measure of risk.