Skip to content
Latchkey

Grype "unable to update vulnerability database" in CI

Grype refreshes its vulnerability database from a listing endpoint before scanning. If CI cannot reach it, or the download is throttled or corrupt, Grype fails to load the DB and cannot match CVEs. Caching or pre-importing the DB removes the per-run dependency.

What this error means

Grype fails at startup with "failed to load vulnerability db" or "unable to update vulnerability database", sometimes citing a listing URL or a checksum mismatch.

Grype
[0000] ERROR unable to check for vulnerability database update
1 error occurred:
	* failed to load vulnerability db: unable to update vulnerability database:
	  unable to download db: ... 429 Too Many Requests

Common causes

The DB endpoint is throttled or unreachable

Rate limiting (429) or an egress block prevents the DB download, so Grype has no data to match against.

A corrupted or stale cached DB

A partial download or a stale listing leaves the cache in a state Grype refuses to load.

How to fix it

Cache the Grype DB across runs

Persist the DB directory so runs reuse it and only refresh when needed.

.github/workflows/ci.yml
- uses: actions/cache@v4
  with:
    path: ~/.cache/grype/db
    key: grype-db-${{ github.run_id }}
    restore-keys: grype-db-

Update the DB once, then scan offline

Refresh the DB in a dedicated step and set Grype to skip further update checks during the scan.

Terminal
grype db update
GRYPE_DB_AUTO_UPDATE=false grype myimage:latest --fail-on high

How to prevent it

  • Cache ~/.cache/grype/db so the DB is reused between runs.
  • Separate grype db update from the scan and disable auto-update.
  • Retry transient DB downloads rather than failing the job.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →