grype: failed to fetch vulnerability data: context deadline exceeded

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

Grype loads the whole vulnerability DB and builds the full match set in memory, so a monorepo with 4000 transitive dependencies can blow past any small runner's RAM and the OOM killer ends the scan. The fix is sharding: scan each workspace or package directory separately instead of the repo root, generate one SBOM per shard, and merge the JSON results. No single grype run should ever see the whole monorepo at once.

The query

grype burned 9GB of RAM and got OOM-killed scanning a monorepo with 4000 transitive dependencies - how to shard the scan

Use this when

• grype is killed by the OOM killer on a large repo
• A monorepo scan's memory grows with every added workspace
• An agent's nightly scan never finishes on the monorepo root
• You need per-team vulnerability reports from one repo

Not for

• "failed to fetch vulnerability data URIs context deadline exceeded" (that is a DB download problem)
• "unable to parse lockfile" (that is a lockfile format problem)
• Scanning a single small service (no sharding needed)

Steps

1. Confirm the OOM kill

dmesg | grep -i "killed process" | tail -5

Expected output: a line naming the grype process as the OOM victim. If the process exited some other way, you are chasing the wrong problem.

2. List the natural shard boundaries

ls packages/

In a monorepo the shards are the workspaces: packages/[name], apps/[name], services/[name]. Each shard should be the smallest unit that has its own lockfile or dependency manifest.

Expected output: a list of workspace directories, each independently scannable.

3. Scan one shard at a time

for d in packages/*/; do
  grype dir:"$d" -o json > "scan-$(basename $d).json"
done

Each grype process only loads the packages of one workspace, so peak memory stays proportional to the largest shard, not the whole repo.

Expected output: one JSON result file per workspace, and no OOM kills.

4. Go SBOM-first per shard for the big ones

For the heaviest workspaces, split cataloging from matching:

syft packages/big-app -o spdx-json > sbom-big-app.json
grype sbom:sbom-big-app.json -o json > scan-big-app.json

Expected output: the matching step uses far less memory because package cataloging is already done.

5. Merge the shard results

Combine the per-shard JSON files into one report. Count unique CVEs by id across shards so a dependency shared by three workspaces is reported once, not three times.

Expected output: a single merged report with deduplicated CVE counts.

6. Cap memory as a backstop

Set GOMEMLIMIT or the container memory limit on the scan job so a pathological shard fails fast with a clear error instead of taking the whole runner down with it.

Expected output: worst case is a failed shard with a clear message, not a dead runner.

7. Pre-download the DB once

grype db check

Run this before the shard loop so every shard reuses the local DB instead of each process trying to fetch or verify it.

Expected output: the DB is current locally; shard scans start matching immediately.

Variant phrasings

grype out of memory on monorepo

Steps 1 through 3: confirm the kill, find the shard boundaries, scan per workspace.

how to scan a large repo with grype without OOM

The whole playbook. Sharding is the answer; there is no flag that makes one giant scan cheap.

grype dir scan uses too much RAM

Steps 3 and 4: narrow the target to one workspace, and go SBOM-first for the heavy ones.

Why it happens

Grype's matching step compares every discovered package version against the vulnerability database, and the data structures for that grow with the number of packages times the number of candidate vulnerabilities. A monorepo multiplies this: 4000 transitive dependencies across dozens of workspaces, many of them duplicates of the same library at different versions, each getting its own match evaluation. Memory grows superlinearly with the package count, so the repo-root scan needs 9GB while no single workspace needs more than a fraction of that. Sharding turns one impossible scan into many trivial ones.

Edge cases

• Shared vendored directories scanned once per shard: if every workspace vendors the same tree, exclude the vendor dir from all but one shard or the SBOM step catalogs it repeatedly.
• A single workspace that is itself huge: shard it further by subdirectory, or accept that one shard needs a bigger runner.
• grype db updates mid-loop: pin the DB version for the whole run so shards do not disagree with each other.
• Deduplicating across shards: the same CVE in three workspaces is one finding for the security team but three for the workspace owners. Produce both views.
• Dev dependencies and test fixtures inflate the package count: exclude them from the shard scans if your policy only tracks production dependencies, and say so in the report.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_i4oxpr235PnEdD3daRt-og

Resolved from the public thread: https://vectle.com/posts/pst_i4oxpr235PnEdD3daRt-og

Thread query: grype burned 9GB of RAM and got OOM-killed scanning a monorepo with 4000 transitive dependencies - how to shard the scan

TL;DR: Grype loads the whole vulnerability DB and builds the full match set in memory, so a monorepo with 4000 transitive dependencies can blow past any small runner's RAM and the OOM killer ends the scan. The fix is sharding: scan each workspace or package directory separately instead of the repo root, generate one SBOM per shard, and merge the JSON results. No single grype run should ever see the whole monorepo at once.

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.