Trivy "failed to download vulnerability DB" (ghcr rate limit) in CI

Trivy pulls its vulnerability database as an OCI artifact from ghcr.io. Unauthenticated CI runners share an IP-based rate limit, so the pull returns TOOMANYREQUESTS and Trivy cannot initialize the scan. Authenticating to ghcr or caching the DB fixes it.

What this error means

Trivy fails during startup with "failed to download vulnerability DB" and a nested "GHSA" / OCI error mentioning "TOOMANYREQUESTS" or "429 Too Many Requests" from ghcr.io, before scanning any layers.

2026-06-30T10:20:31.004Z	FATAL	init error: DB error: failed to download vulnerability DB:
OCI repository error: 1 error occurred:
	* GET https://ghcr.io/v2/aquasecurity/trivy-db/manifests/2: TOOMANYREQUESTS: retry-after: 512ns

Common causes

Anonymous ghcr pulls hit the shared rate limit

The DB is served from ghcr.io. Many runners on the same egress IP exhaust the unauthenticated limit, so the DB manifest returns TOOMANYREQUESTS.

The DB is re-downloaded on every run with no cache

Without a cache, each job fetches the full DB, multiplying requests and making the limit far easier to hit.

How to fix it

Authenticate to ghcr before scanning

Log in to ghcr.io with the workflow token so DB pulls use the higher authenticated limit.

- uses: docker/login-action@v3
  with:
    registry: ghcr.io
    username: ${{ github.actor }}
    password: ${{ secrets.GITHUB_TOKEN }}
- run: trivy image --exit-code 1 --severity HIGH,CRITICAL myimage:latest

Cache the Trivy DB across runs

Persist the DB directory so most runs skip the download entirely and only refresh when stale.

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

How to prevent it

• Authenticate to ghcr.io in CI so DB pulls are not anonymous.
• Cache ~/.cache/trivy so the DB is reused between runs.
• Consider a mirrored DB registry (TRIVY_DB_REPOSITORY) for large fleets.

Related guides