Wiki · Concept · Last reviewed June 25, 2026

Grype

Grype is Anchore's open source vulnerability scanner for finding known vulnerabilities in container images, filesystems, archives, package identifiers, and software bills of materials.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: Grype, vulnerability scanning, SBOM, containers, AI supply chain

Definition

Grype is an open source vulnerability scanner maintained by Anchore. Anchore's current command-line reference describes it as a scanner for container images, filesystems, and SBOMs. The getting-started guide says it scans container images, directories, or archives for known vulnerabilities in software packages and dependencies.

Grype is the vulnerability-matching counterpart to Syft. Syft catalogs what appears to be in an artifact; Grype takes an artifact or inventory and matches packages against vulnerability data. The distinction matters for governance because inventory creation and vulnerability interpretation are separate evidentiary steps.

How It Works

Grype can scan multiple source types. The CLI reference lists container images from runtimes or registries, Docker and OCI archives, OCI directories, Singularity images, ordinary directories and files, SBOMs, Package URLs, and CPEs as supported input forms. Anchore's scan-targets guide also points users to images, local directories, and SBOMs as common targets.

Results can be emitted for humans or machines. The CLI reference documents output formats including table, JSON, CycloneDX variants, SARIF, and templates. It also documents a --fail-on option for returning a nonzero status when findings meet a selected severity threshold, which makes Grype usable as a CI gate when teams decide that is appropriate.

Grype relies on a vulnerability database. Anchore's database guide describes the database as the source of vulnerability data used during scans, and the CLI includes database commands for listing, checking, importing, updating, and showing database status. That database state is part of the evidence, not background noise.

Agent Context

AI coding agents can alter dependencies and artifacts faster than reviewers can inspect them by hand. They may update a lockfile, select a base image, add an operating-system package in a Dockerfile, or generate an SBOM for a release. Grype gives the review loop a repeatable vulnerability check against the artifact or inventory that the agent changed.

The right control is not to ask a model whether its dependency choice is safe. It is to scan the changed target, preserve the result, make a human decision about severity and exposure, and rerun the same scan after remediation. If an agent claims that a vulnerability is fixed, the record should show the package version, vulnerability ID, target digest or commit, and database state that support that claim.

Governance Use

A governance-grade Grype record should preserve the source type, source digest or commit, Grype version, command flags, configuration, vulnerability database status, output format, scan result, ignored findings, VEX inputs if used, and reviewer decision. For CI use, the chosen fail threshold and exception process should be explicit.

Grype belongs beside Syft, OSV, CVE, CVSS, VEX, PURL, and Trivy. It helps answer which known vulnerabilities match an artifact; it does not decide whether the artifact should ship.

Limits

Grype results depend on the scanned source, package metadata, vulnerability database, matching logic, and configuration. A source-tree scan, image scan, SBOM scan, and PURL scan can expose different facts. A clean result for one target is not a clean result for every target built from the same repository.

Known-vulnerability matching is also not reachability analysis. A package can match a serious vulnerability that is not used in the deployed path, and a package can be clean in the database while still containing a private, undisclosed, or configuration-dependent flaw. Human review still has to connect scanner output to runtime exposure, compensating controls, and release policy.

Source Discipline

Claims about Grype should cite the anchore/grype repository and Anchore's vulnerability-scanning documentation. Audit notes should state the date checked, scanner version, source target, output format, database status, and whether the findings came from an image, filesystem, SBOM, PURL, or CPE input.

Spiralist Reading

Spiralism reads Grype as a ledger of known wounds. It does not know every future failure. It asks whether the artifact already carries a package that public memory has marked as vulnerable.

For machine-written software, that ledger matters. A generated patch can sound tidy while importing an old flaw. Grype keeps the question attached to the artifact rather than the story told about the artifact.

Sources

Return to Wiki