Why a second scanner • Use cases • Input • Output • Pricing

Grype Vulnerability Matcher

A second, independent CVE scanner for any container image or public repo — real matches from NVD, GHSA, and distro feeds.

Verified live against python:3.9-slim: 337 real matches found (16 Critical, 94 High, 123 Medium, 14 Low, 54 Negligible, 36 Unknown), each with severity, fix state, and a working data-source link — no invented CVE IDs.

Why a second scanner alongside Trivy

Grype and Trivy use overlapping but not identical vulnerability databases and matching logic. Findings that show up in one but not the other are common in practice — running both against the same target is a legitimate cross-check, and multi-scanner coverage is a real requirement for many compliance programs, not redundancy for its own sake.

What you get

• Real CVE matches from Grype's combined NVD, GitHub Security Advisories, and Linux-distro vulnerability feeds — nothing invented or templated.
• Severity, installed version, fix state, and fixed-version-if-available on every match.
• A scan_summary row with totals by severity so you don't have to count rows yourself.
• Works against both container images and public git repos, auto-detecting which one you gave it.
• Only charges on a successfully completed scan — a bad target or clone failure isn't billed.

How it works

target (image or repo URL)
   |
   v
scanType auto-detected (image vs repo)
   |
   v
git clone --depth 1  (repo targets only)
   |
   v
grype <target> -o json   (DB baked in at build time, no runtime download)
   |
   v
severity/fixable filters applied
   |
   v
one dataset row per match + one scan_summary row

Use cases

• Second-opinion CVE check — run alongside Trivy on the same image and diff the two match lists before a release ships.
• Compliance programs that require multi-scanner coverage — some frameworks explicitly ask for more than one vulnerability data source.
• Base image comparison — compare Grype's match count across candidate base images before standardizing.
• Public repo dependency audit — point it at a git URL to check for known-vulnerable dependencies without cloning locally.

Input

Field	Type	Required	Notes
target	string	yes	Container image (nginx:1.19) or git repo URL
scanType	string	no	image or repo — auto-detected if left blank
severityFilter	array	no	Restrict results to given severities
onlyFixable	boolean	no	Skip vulnerabilities with no available fix

{ "target": "python:3.9-slim", "severityFilter": ["Critical", "High"] }

Output

One row per real CVE match (ID, severity, package, installed version, fix state and version, data source), plus one scan_summary row with totals by severity.

Sample output

Three real findings from the live-verification run above (338 total rows: 337 matches + 1 summary):

{
  "findingType": "vulnerability",
  "target": "python:3.9-slim",
  "vulnerabilityId": "CVE-2025-15467",
  "severity": "Critical",
  "pkgName": "libssl3t64",
  "installedVersion": "3.5.1-1+deb13u1",
  "pkgType": "deb",
  "fixState": "fixed",
  "fixedVersions": ["3.5.4-1~deb13u2"],
  "dataSource": "https://security-tracker.debian.org/tracker/CVE-2025-15467",
  "description": "Issue summary: Parsing CMS AuthEnvelopedData or EnvelopedData message with maliciously crafted AEAD parameters can trigger a stack buffer overflow..."
}

And the scan_summary row from the same run:

{
  "findingType": "scan_summary",
  "target": "python:3.9-slim",
  "scanType": "image",
  "totalMatches": 337,
  "totalReturned": 337,
  "severityCounts": { "Critical": 16, "High": 94, "Medium": 123, "Negligible": 54, "Low": 14, "Unknown": 36 },
  "status": "COMPLETED",
  "scannedAt": "2026-08-01T16:56:36.573416+00:00"
}

Pricing

Pay per completed scan (Pay-Per-Event) — $0.79 per scan, charged once the scan finishes regardless of how many matches are found. Failed scans are never charged.

Frequently asked questions

How is this different from the Trivy Actor? Different underlying tool, different vulnerability database composition (NVD/GHSA/distro feeds vs. Trivy's own aggregated sources), different matching logic. They frequently agree but not always — that's the point of running both.

Does it need a fresh database download on every run? No — the vulnerability database is updated and baked into the Docker image at build time, and the Actor is explicitly configured to skip runtime database checks (GRYPE_DB_AUTO_UPDATE=false), so every run scans immediately instead of waiting on a network fetch.

Can I scan a private image or repo? No — only public registries and public git URLs are supported; there's no credential input for private targets.

What if there are zero matches? You get zero vulnerability rows and a scan_summary row with totalMatches: 0 — a clean target isn't padded with findings to look more substantial.

Limitations

• Only public container images and public git repos are supported.
• The vulnerability database reflects the image's build time, not the live moment of your scan — refreshed periodically, not on every run.
• onlyFixable filters out real findings that don't yet have a fix available; leave it off if you want the complete picture including unfixed CVEs.

Related Actors

Part of a five-Actor security scanning catalog: Trivy Security Scanner (CVEs + secrets + misconfigurations in one scan), Gitleaks Secret Scanner (full git-history secret detection), Syft SBOM Generator (CycloneDX/SPDX bill of materials), OSV-Scanner Vulnerability Checker (lockfile-based OSV.dev checks).

Start scanning

Give it a container image or a public repo URL and run it — add severityFilter if you only care about Critical/High, or onlyFixable if you only want actionable results.