grype db check: vulnerability database is 14 days old warning - how to f

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: 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.

TL;DR: Get a fresh grype DB archive built for your exact grype version, check the tarball is intact, and re-run the install with the full path. This error means grype could not read the archive as a valid vulnerability database, and the cause is almost always a truncated download or a schema mismatch between the DB build and the grype release. A matching, intact archive installs cleanly.

failed to install vulnerability database from local file

1. Check the archive is not truncated. Run tar tzf [PATH-TO-ARCHIVE] and skim the listing.

Expected: you see database files listed (vulnerability.db plus metadata files). A gzip or tar error means the download was cut short, so re-download it on the connected machine.

2. Confirm your grype version. Run grype version.

Expected: output shows the release and the DB schema version it expects. The archive must be a DB built for that schema; a DB built for a newer grype release will not install on an older one.

3. Fetch a fresh archive on a connected machine running the same grype release, then carry it to the airgapped host. Matching releases on both sides matters more than anything else here.
4. Re-run the install with the absolute path: grype db install [ABSOLUTE-PATH-TO-ARCHIVE].

Expected: grype reports the vulnerability database installed successfully.

5. Verify with grype db check.

Expected: output shows a valid database with a build date and the expected schema version.

Use this when

• grype db install fails on an offline or airgapped host
• you carried the DB archive between machines by hand or on removable media
• the archive came from a browser or curl download that may have been interrupted
• grype was upgraded after the archive was built

Not for this skill when

• the failure is a network fetch (grype db update on a connected host); that is a proxy or connectivity problem, not an archive problem
• the scan itself fails after the database installed; that is a matcher or target problem
• you run grype against a centralized database server instead of a local DB file

Variant phrasings

grype db install fails offline with a local tarball

error installing vulnerability database from a file path

grype airgap setup rejects the database archive

vulnerability.db archive not recognized by grype db install

Why it happens

The install step does not just copy a file. It opens the archive, checks the layout, and validates the embedded schema version against the running grype build. A partial download fails the read, and a DB built for a different schema version fails validation. Both surface as the same generic install failure, which is why the fix is always a fresh, version-matched, intact archive.

Edge cases

• The user running grype must be able to read the archive and write the DB cache directory. A root-owned archive installed by a CI user fails with the same message, so check ownership when the archive itself is fine.
• If the connected download machine and the airgapped host run different grype releases, fetch the archive with the exact release that runs offline.
• Custom DB builds from a hand-rolled vunnel run can lag behind the schema the release expects; prefer the official DB archive for your grype version.
• Treat grype db check as the source of truth after install. The install command's exit code alone can mislead wrapper scripts, so gate the scan on the check.

Provenance

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

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

Thread query: grype airgap install: "failed to install vulnerability database from local file"

TL;DR: