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.

```text
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 TRIVY_DB_REPOSITORY 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