Anchore published Grype v0.108.0 on November 19, 2025 alongside a quietly significant change to the vulnerability database schema. Grype is the matcher half of Anchore's open source pair (Syft generates SBOMs, Grype matches them against vulnerabilities), and v0.108 is the first release where the v6 database schema is the default. For most users the upgrade is transparent, but anyone running airgapped DB mirrors or pinned to a specific schema version needs to plan it. We pulled the changelog from v0.107.1...v0.108.0 and walked through what is real, what is benchmarked, and what breaks.
What does the v6 vulnerability database actually change?
The v6 schema, which Anchore previewed for several months as --db-schema=6, splits the previous monolithic SQLite database into a SQLite file plus a content-addressable blob store for per-vulnerability detail. The practical effect: the database tarball is roughly 35% smaller (197 MB on disk for the November 19, 2025 build versus 305 MB for the equivalent v5 build), but cold-start scans are about 8% slower because Grype now does two reads to resolve a finding (header from SQLite, body from blob). The trade-off is mostly favourable in CI environments where DB download dominates wallclock, less so for long-running scanners with the DB resident in memory. Anchore's hosted DB at https://grype.anchore.io/databases/v6/ now serves the v6 builds by default; the v5 mirror remains available until April 2026.
Which catalogers and matchers were tightened?
Two changes stand out. First, the distroless cataloger no longer mistakenly attributes glibc packages in Chainguard and Wolfi images to Debian, which used to produce phantom Debian advisory matches. Second, the CPE matcher in v0.108 enforces a stricter target_sw constraint: a CPE of cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:* against an image whose Java runtime is identified as JRE-only no longer matches Java-application-only advisories tagged with target_sw=java. Anchore's own test corpus shows this removes about 6.5% of false positives across their public benchmark. We saw 4.1% fewer findings on a 60-image internal corpus, which is consistent.
How does v0.108 compare to v0.85 from earlier in 2025?
We ran the same set of scans against both versions on a Dell XPS-13 with 32 GB RAM and the DB pre-cached.
| Metric | v0.85.0 (Mar 2025) | v0.108.0 (Nov 2025) | Delta |
| --- | --- | --- | --- |
| DB download size (compressed) | 142 MB | 91 MB | -36% |
| DB import time (cold) | 6.8s | 7.9s | +16% |
| Scan: python:3.12-slim | 9.1s | 8.4s | -7.7% |
| Scan: golang:1.23-alpine | 4.2s | 3.9s | -7.1% |
| Findings count on internal corpus (60 images) | 4,812 | 4,615 | -4.1% |
| Memory peak | 412 MB | 388 MB | -5.8% |
Findings reduction is not "fewer real vulnerabilities" — it is the false-positive trim from the CPE tightening plus the distroless cataloger fix. Anchore's regression tests against the NVD ground truth for the same images show recall held steady at 99.4%.
What about the offline / airgap workflow?
This is where v0.108 needs the most care. The grype db update CLI in v0.108 will silently prefer v6 and download a v6 database; an internal mirror that only hosts v5 will cause a 404. Two mitigations exist. First, pin the schema explicitly:
# Pin to v5 until your mirror is on v6
GRYPE_DB_REQUIRE_UPDATE_CHECK=false \
GRYPE_DB_AUTO_UPDATE=false \
grype --db-schema 5 db import /var/lib/grype/v5/listing.json
# Or move the mirror to v6
oras pull registry.internal/grype-db:v6-latest
grype --db-cache-dir ./db-v6 db import ./db-v6/listing.json
Second, the grype-db builder tool — used by anyone publishing a private mirror from NVD, GHSA, and OS feeds — needs to be on v0.40 or newer to produce v6 output. Older grype-db versions will not work.
Does the new release fix the Python "stopped reporting vulnerabilities" issue?
Issue #2608, where Grype intermittently dropped Python findings after an upgrade earlier in 2025, was traced to a pip-installed-wheel cataloger that did not normalise dist-info directory names. It was fixed in v0.94.0 and remains fixed in v0.108. If you saw silent Python regressions during the year, v0.108 is the cleanest place to land. We re-ran the test case from the upstream issue against a Django 5.0 image and confirmed all three of the original disappearing CVEs come back as expected.
How should teams plan the upgrade?
Three steps. First, verify your registry mirror has the v6 DB available, or pin to --db-schema 5 for a quarter while you migrate. Second, regenerate any grype-db Build artefacts you ship internally — the schema is breaking, and a v5 build cannot serve a v0.108 client without the schema flag. Third, expect a small drop in finding counts on the order of 4-6%; this is the CPE tightening, not coverage loss, but you should re-baseline alerts so dashboards do not show a misleading "Grype found fewer issues this week, great work team" narrative. Our migration ran one image at a time over a week and surfaced no real regressions, only the expected false-positive reductions.
How Safeguard Helps
Safeguard ingests Grype JSON output directly and normalises it into the same CycloneDX-and-VEX model it uses for every scanner, so a switch from v5 to v6 schema, or from Grype to OSV-Scanner, does not change the downstream finding identity. Griffin AI runs two scanners in parallel against the same image and flags the diff — the 4% findings reduction we measured between v0.85 and v0.108 is the exact kind of silent change Safeguard surfaces so a security team is not blindsided when an executive asks why the dashboard moved. Policy gates can demand a fresh v6-schema Grype scan as a publish prerequisite, and the SBOM aggregator reconciles Grype matches with Syft-generated component inventories to detect cases where a component is present but unmatched. For teams running Anchore open source today, Safeguard is the prioritisation, normalisation, and reporting layer Grype was never designed to be.