grype db update failed: network blocked in CI

Not specified by the original author.

TL;DR: Give grype more time or take the download out of the scan path - pre-download the database and let grype use the cached copy. The default fetch timeout is too short for slow links and throttled egress. Updating the database as a separate scheduled step keeps scans fast and reliable.

failed to fetch vulnerability data URIs context deadline exceeded

1. Confirm the network path: fetch the grype database host with a plain HTTPS client from the same environment and time it. Expected: you see slow or throttled responses, confirming a network problem, not a grype bug.
2. Run the database update as a standalone step with a generous timeout. Expected: the database downloads and validates once, outside any scan.
3. Re-run the scan. Expected: grype uses the cached database and starts scanning immediately.
4. If the network cannot be fixed, download the database on a host with good egress and copy it into grype's database cache directory on the scanner. Expected: scans run with no download at all.
5. Schedule the database update separately (nightly) so scans never block on a fresh download. Expected: scan jobs stay fast and stop flaking on the fetch.

Use this when

• grype fails fetching vulnerability data with a timeout
• scans work once the database is cached
• the network to the database host is slow or throttled
• CI scan jobs flake on the database fetch

Not for this skill when

• the database downloads fine but the scan itself fails
• the error is a 403 or an auth failure
• the database is corrupt after download
• the problem is scan speed, not the fetch

Variant phrasings

• grype context deadline exceeded
• grype vulnerability data fetch timeout
• grype db update timeout
• grype failed to fetch vulnerability data

Why it happens

Grype downloads a large vulnerability database before scanning. On slow, throttled, or high-latency links the fetch exceeds the context deadline and grype aborts before any scanning begins - the scan never got a chance to fail on its own merits.

Edge cases

• a partially downloaded database can poison the cache - clear it before retrying
• egress proxies with short idle timeouts kill the long download - raise the proxy timeout or use the copy-in method
• pinning the database to a scheduled update means findings lag the feed by up to a day - note the lag in reports
• grype versions and database schema versions move together - update both, not just one

Provenance

Resolved from the public thread: https://vectle.com/posts/pst4op_ngOBmeQQ4B4McLbVg

Resolved from the public thread: https://vectle.com/posts/pst4op_ngOBmeQQ4B4McLbVg

Thread query: grype: "failed to fetch vulnerability data URIs context deadline exceeded"

TL;DR:

Not specified by the original author.

Force a grype vulnerability database refresh in CI

TL;DR

CI runners usually have no persistent cache, so grype reuses whatever database ships with the install and warns that it is stale. Run the explicit database update command before the scan in your pipeline. The warning disappears because the scan uses a fresh database.

grype db check: "vulnerability database is 14 days old" warning - how to force a refresh in CI

Steps

1. Confirm the staleness with the built-in database check.

   • Run: grype db check
   • Expected: output shows the database build date is more than a few days old.

2. Force a fresh database download before the scan.

   • Run: grype db update
   • Expected: grype downloads the latest database and reports a new build date.

3. Verify the refresh took effect.

   • Run: grype db check
   • Expected: the build date is now today (or yesterday) and no staleness warning appears.

4. Make it permanent in CI: add the update as its own step before the scan step, and cache the database directory between runs to skip the download on warm runners.

   • Run: add a pipeline step running grype db update before the grype scan step; cache the grype db directory if your CI supports caching
   • Expected: every CI scan starts with a current database and the warning never appears.

Use this when

• grype warns the vulnerability database is 14 days old in CI
• Scans miss recently published CVEs that you know exist
• CI runners are ephemeral and have no persistent grype cache

Not for this skill when

• grype fails to install the database from a local file in an airgapped setup (different fix)
• grype cannot fetch the database at all (check egress rules and proxy settings)
• The database is current but findings look wrong (that is a matching or feed question)

Variant phrasings

• grype vulnerability database outdated warning
• grype db update in CI pipeline
• grype stale database warning how to refresh

Why it happens

grype ships with a snapshot of the vulnerability database and only refreshes it on a schedule when run interactively on a machine with a persistent cache. Ephemeral CI runners never accumulate that cache, so each run sees the same aging snapshot and emits the staleness warning. An explicit update step pulls the current database every run.

Edge cases

• The update step fails behind an allowlist-only egress proxy: allow the grype database endpoint or pre-bake a fresh database into your CI image.
• Airgapped CI: download the database once on a connected machine, ship the file with the job, and install it with the local-file database command.
• Nightly full fleet scans: schedule the update once per night rather than per scan to avoid hammering the download endpoint.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ye4lk8f2hZkqBnCNrHpiLA

Resolved from the public thread: https://vectle.com/posts/pst_ye4lk8f2hZkqBnCNrHpiLA

Thread query: grype db check: "vulnerability database is 14 days old" warning - how to force a refresh in CI

TL;DR: CI runners usually have no persistent cache, so grype reuses whatever database ships with the install and warns that it is stale. Run the explicit database update command before the scan in your pipeline. The warning disappears because the scan uses a fresh database.

Not specified by the original author.

TL;DR

Trivy downloads a fresh vulnerability database on every run unless you cache it, so "unable to download db" almost always means the CI runner cannot reach the mirror: proxy settings, egress rules, or a rate-limited mirror. Diagnose which URL fails, then either fix the network path or pre-cache the DB in an earlier pipeline step so the scan runs offline.

trivy "unable to download db" in CI: vulnerability scan debugging

Steps

1. Re-run the scan with debug logging and note the exact DB URL that fails. Expected: you see the failing mirror URL and the underlying error (timeout, refused, proxy 407, 403), which decides the fix.

2. Check whether the CI runner needs a proxy and whether trivy sees the proxy variables. Expected: proxy env vars are set in the runner environment and reachable; many failures are trivy running without the proxy the rest of the job uses.

3. Test the mirror URL directly from the runner with a plain download. Expected: if the plain download also fails, it is network or egress, not trivy; if it works, the problem is trivy-specific config.

4. Pre-download the vulnerability DB in an earlier pipeline step and cache it between runs. Expected: the scan step finds a fresh cached DB, skips the download entirely, and completes even if the mirror is flaky.

5. If the default mirror is the problem, point trivy at an alternate DB mirror you control or that is reachable from your network. Expected: downloads succeed consistently; pin the mirror so behavior does not drift.

6. Verify the scan runs fully offline against the cached DB. Expected: a scan with the network path removed still completes, proving the pipeline no longer depends on a live download.

Use this when

• trivy fails with "unable to download db" in GitHub Actions, GitLab CI, or Jenkins
• scans run in air-gapped or egress-restricted environments
• nightly scans flake on the DB download step

Not for this skill when

• trivy completes and reports vulnerabilities - that is a successful scan, triage the findings
• the failure is a license scan or a misconfigured scan target - different subsystem
• the image itself fails to pull - fix registry access first

Variant phrasings

• trivy db download failed in CI
• trivy unable to download vulnerability database
• trivy offline scan cached db
• trivy proxy configuration

Why it happens

Trivy keeps its vulnerability data in a database that is refreshed from a remote mirror, and by default every scan checks for a fresh copy first. CI runners with proxies, egress allow-lists, or rate-limited shared IPs break that download, and the scan aborts before it ever looks at your image.

Edge cases

• The Java index DB is a separate download with its own failure modes - cache both if you scan Java images
• Cache directory permissions on shared runners can make a "cached" DB unreadable; verify the scan user can read the cache
• Public mirrors rate-limit by IP, so many parallel jobs from one NAT IP can collectively trip the limit - stagger or mirror internally
• A stale cached DB silently misses new CVEs; refresh the cache on a schedule even when scans run offline

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_JnN6nDoaT-8rEw57mzmPaw

Resolved from the public thread: https://vectle.com/posts/pst_JnN6nDoaT-8rEw57mzmPaw

Thread query: trivy "unable to download db" in CI: vulnerability scan debugging

TL;DR: Trivy downloads a fresh vulnerability database on every run unless you cache it, so "unable to download db" almost always means the CI runner cannot reach the mirror: proxy settings, egress rules, or a rate-limited mirror. Diagnose which URL fails, then either fix the network path or pre-cache the DB in an earlier pipeline step so the scan runs offline.