trivy unable to download db in CI: vulnerability scan debugging

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.

Not specified by the original author.

TL;DR

Your corporate proxy terminates TLS and re-signs it with its own CA, which trivy's certificate pool does not trust. The fix is to make that CA trusted: install the proxy's CA certificate into the OS trust store, or point SSLCERTFILE at the CA bundle before running trivy. Then confirm the DB downloads with a standalone fetch before the next scan.

The query

trivy fails with "x509: certificate signed by unknown authority" when downloading the vulnerability DB behind a TLS-intercepting proxy

Use this when

• trivy fails on the DB download step with an x509 error, and the network runs a TLS-intercepting proxy
• The same scan works off the corporate network or VPN
• curl to the DB host also fails with a certificate complaint

Not for

• "FATAL failed to download vulnerability DB" with a DNS or connection timeout (reachability, not trust)
• Registry pull failures with "unauthorized" (authentication, not TLS)
• An expired or revoked certificate on a host you control (fix the cert, not the trust store)

Steps

1. Prove it is the proxy, not trivy

curl -sI https://aquasecurity.github.io | head -5

Expected output: a curl certificate error naming the issuer. If curl succeeds but trivy fails, the gap is trivy's cert pool, not the proxy.

2. Get the proxy CA certificate

Ask your IT team for the proxy's root CA in PEM format, or export it from your workstation's certificate store. Save it where the scan runner can read it.

Expected output: a PEM file starting with the BEGIN CERTIFICATE marker.

3. Make the CA trusted for the scan

Option A, OS store (persistent on the runner):

cp corp-proxy-ca.pem /usr/local/share/ca-certificates/ && update-ca-certificates

Option B, environment variable (per run):

export SSL_CERT_FILE=/path/to/corp-proxy-ca.pem

Expected output: curl to the DB host now completes without a certificate error.

4. Warm the DB as a standalone step

trivy image --download-db-only

Expected output: trivy reports the vulnerability DB downloaded and updated, with no x509 error.

5. Bake the fix into the pipeline

Add the CA install to the runner image or the pipeline's setup step so every future run trusts the proxy from the start. Verify: a fresh runner with an empty cache completes a trivy scan on a small test image.

Variant phrasings

trivy x509 certificate signed by unknown authority

The short form of this error, same fix.

trivy vulnerability DB download fails behind corporate proxy

Symptom-level phrasing from operators who have not read the x509 line yet.

Compatibility: trivy 0.4x and later, which fetch the vulnerability DB over HTTPS from the public mirror. Go's TLS stack honors SSLCERTFILE and the OS trust store.

Why it happens

A TLS-intercepting proxy sits between trivy and the DB mirror, presenting a certificate signed by a corporate CA that trivy's bundled certificate pool does not know. Trivy correctly refuses the connection because the chain does not anchor to a trusted root. Both sides are working as designed; the missing piece is the corporate CA in trivy's trust path.

Edge cases / pitfalls

• The proxy CA rotates. When DB downloads break again months later, check the CA expiry date before debugging anything else.
• An allowlist-only egress proxy can also block the DB mirror host outright. If trusting the CA still fails, confirm the mirror host is on the allowlist.
• Do not reach for any "skip TLS verification" workaround. You would trade a visible trust problem for an invisible one.
• Minimal container images often lack update-ca-certificates. Use the SSLCERTFILE approach there.

Provenance

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

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

Thread query: trivy fails with "x509: certificate signed by unknown authority" when downloading the vulnerability DB behind a TLS-intercepting proxy

TL;DR: Your corporate proxy terminates TLS and re-signs it with its own CA, which trivy's certificate pool does not trust. The fix is to make that CA trusted: install the proxy's CA certificate into the OS trust store, or point SSLCERTFILE at the CA bundle before running trivy. Then confirm the DB downloads with a standalone fetch before the next scan.

Not specified by the original author.

TL;DR: Point trivy at the new database mirror location, clear the stale cached database, and let it re-download. Trivy refuses to scan without a current vulnerability database, so a moved mirror is a hard stop, not a warning. If egress is restricted, download the database once on an allowed host and run the scan offline.

FATAL failed to download vulnerability DB

1. Check the database cache age: look in trivy's cache directory for the database files and note their timestamps. Expected: the cache is stale or missing, confirming the download is the failure point.
2. Update the database mirror setting to the new location (the TRIVYDBREPOSITORY setting), or remove the override if the default moved. Expected: the setting names a reachable mirror.
3. Clear the stale cache so trivy performs a clean download. Expected: the cache directory no longer holds the old database files.
4. Re-run the scan and watch the first lines of output. Expected: the vulnerability database download completes and the scan proceeds.
5. For locked-down networks, download the database tarball on a host with egress, copy it in, and run the scan with the offline-scan flag. Expected: the scan runs with no network calls.

Use this when

• trivy fails before scanning with a database download error
• the database mirror moved or changed URL
• scans worked before a mirror change and broke after
• trivy reports a stale or missing vulnerability database

Not for this skill when

• trivy downloads the database fine but fails mid-scan
• the error concerns the Java database or another component
• the failure is a TLS certificate error behind a proxy (a proxy problem, not a mirror problem)
• you want fully offline scanning by design (use the offline step instead)

Variant phrasings

• trivy FATAL vulnerability DB download failed
• trivy cannot download vulnerability database
• trivy db mirror moved
• trivy failed to download db

Why it happens

Trivy downloads its vulnerability database from a mirror on first run and on refresh. When the mirror moves, the old URL returns 404 or times out, and trivy treats a missing database as fatal because every finding depends on it.

Edge cases

• corporate proxies that intercept TLS break the download with a certificate error, not a 404 - that is a proxy problem, not a mirror problem
• a partially downloaded database corrupts the cache - always clear before retrying
• air-gapped setups need the database refreshed on a schedule, or findings silently age out
• pinning trivy and the database version together avoids format mismatches after upgrades

Provenance

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

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

Thread query: trivy: "FATAL failed to download vulnerability DB" after the db mirror moved

TL;DR: