What vulnerability databases does Trivy use and how are they updated?

Trivy's vulnerability databases are like the reference libraries that a medical diagnostic system uses to identify diseases. Without up-to-date reference data, the system cannot detect newly discovered conditions. Similarly, Trivy's scanning accuracy depends entirely on the freshness and completeness of its vulnerability databases. Understanding where this data comes from and how it stays current is fundamental to trusting scan results.

Trivy maintains two databases that work together. The primary vulnerability database (trivy-db) contains all known CVE entries aggregated from multiple upstream sources. These sources include the National Vulnerability Database (NVD), which is the U.S. government's comprehensive CVE repository, distribution-specific advisory databases like Debian Security Tracker, Alpine SecDB, Red Hat OVAL, Ubuntu CVE Tracker, and Amazon Linux Security Advisories, and language-specific advisory databases like GitHub Advisory Database, RustSec Advisory Database, Go Vulnerability Database, and PHP Security Advisories. The second database (trivy-java-db) specifically indexes Java archives (JAR files) to map them to their Maven coordinates, enabling accurate vulnerability matching for Java applications like an order-processing-service built with Spring Boot.

The update mechanism is designed for reliability and speed. Trivy's databases are packaged as OCI artifacts and hosted on GitHub Container Registry (ghcr.io). When you run a scan, Trivy checks whether the local cached database is older than the update interval (default is 24 hours since the last successful update). If it is, Trivy pulls the latest database from the registry. The database itself is updated by the Trivy maintainers approximately every 6 hours, meaning newly published CVEs typically appear in Trivy's database within 6 to 12 hours of publication. The database download is incremental when possible, reducing bandwidth usage for teams scanning services like payments-api, user-auth-service, and checkout-service multiple times a day.

In production environments, database management becomes a critical operational concern. For CI/CD pipelines building images for inventory-sync or other services, teams cache the database directory (~/.cache/trivy/db) between pipeline runs to avoid downloading it on every build. In air-gapped environments where build agents cannot access ghcr.io, teams set up an internal OCI registry mirror. An internet-connected machine downloads the database using trivy image --download-db-only, then pushes the OCI artifact to the internal registry. Trivy is then configured with --db-repository to point to the internal mirror. Some organizations run a cron job that updates the mirror every 6 hours to stay current. The --skip-db-update flag is available to prevent Trivy from attempting any database download, which is necessary in fully offline scenarios.

A subtlety beginners often overlook is the difference between the database update frequency and the upstream advisory publication speed. Even though Trivy updates its database every 6 hours, the upstream sources (NVD, distribution advisories) may take days or weeks to publish a CVE after a vulnerability is disclosed. Trivy can only report what its sources have published. For zero-day vulnerabilities, there is an inherent delay. Additionally, the --skip-db-update flag is dangerous if used without understanding: if the cached database is months old, Trivy will happily scan your checkout-service image and report it as clean, missing hundreds of vulnerabilities that were published after the cache was last refreshed.