Trivy, Aqua Security's open source scanner, doesn't discover vulnerabilities on its own — it matches the packages it finds against a vulnerability database that Aqua assembles from more than a dozen upstream feeds and ships as trivy-db, a compact BoltDB file rebuilt roughly every 6 hours and pulled from ghcr.io/aquasecurity/trivy-db. That database blends NVD vulnerability data (NIST's National Vulnerability Database) for baseline CVE metadata, OS vendor trackers (Red Hat OVAL, Debian Security Tracker, Ubuntu CVE Tracker, Alpine secdb, Amazon Linux ALAS, SUSE, Photon OS, Chainguard/Wolfi advisories) for distro-patched packages, and GitHub Security Advisories (GHSA) plus ecosystem feeds for npm, PyPI, RubyGems, Go, and Rust dependencies. kube-hunter, despite living in the same Aqua GitHub org, is not one of these sources — it's a separate active-probing tool with no connection to trivy-db. Here's how the actual pipeline works, where it lags, and where the gaps show up in a scan.
Where does Trivy's vulnerability database actually come from?
It comes from aquasecurity/vuln-list, a GitHub repository that scrapes roughly 15+ upstream advisory sources on a schedule and normalizes them into a common JSON format, which a separate build job then compiles into the trivy-db binary format Trivy downloads at scan time. This two-stage design — scrape into vuln-list, compile into trivy-db — means Trivy itself never talks to NVD, GHSA, or a distro's security tracker during a scan; it only ever queries a local, pre-built snapshot. The practical effect is that Trivy's accuracy is bounded by whatever was true in that snapshot the last time it was refreshed, not by what's true on the vendor's site right now. Aqua publishes trivy-db updates to GHCR on a cron job (historically every 6 hours), so a scan run at 9am and one run at 3pm on the same day can legitimately return different results for the same image.
Does Trivy query NVD directly during a scan?
No — Trivy never calls NVD's live API; it relies on NVD's JSON feed data as it existed when vuln-list last scraped it. This distinction matters a lot right now because NVD has been running a well-documented enrichment backlog since February 12, 2024, when it drastically slowed the rate at which it attaches CPE (Common Platform Enumeration) matches and CVSS scores to newly published CVEs. Thousands of CVEs have sat in NVD's "awaiting analysis" state for months at a time — a backlog that leaves plenty of NVD vulnerability records technically published but functionally unscored. Since Trivy leans on NVD's CPE data to match generic (non-distro-packaged) software — think a Java library that isn't covered by any OS vendor's tracker — a CVE stuck in that backlog can be functionally invisible to Trivy for weeks, not because Trivy failed to update, but because the upstream source it depends on hasn't finished analysis yet.
Which vendor advisories fill in the gaps NVD leaves for OS packages?
For anything installed via a distro's package manager, Trivy prioritizes the OS vendor's own advisory over NVD, pulling from Red Hat's OVAL v2 feed, the Debian Security Tracker's JSON export, the Ubuntu CVE Tracker, Alpine's secdb, Amazon Linux's ALAS/ALAS2023 bulletins, SUSE's CVRF/OVAL data, Photon OS's advisories, and Chainguard/Wolfi's secdb, among others. This matters because NVD scores a CVE against the upstream software version, while a distro like Debian or Amazon Linux frequently backports a security fix into an older package version without bumping the version number — something NVD's generic matching logic doesn't know how to interpret. If Trivy relied on NVD alone for a Debian 12 image, it would flag hundreds of packages as vulnerable that the distro already patched months earlier via backport. The vendor-advisory layer is what lets Trivy report "fixed in 1:2.37-1+deb12u2" instead of a blanket false positive.
How does Trivy cover vulnerabilities in application dependencies like npm or PyPI packages?
For language ecosystems, Trivy relies primarily on GitHub Security Advisories (GHSA), a database that has grown to well over 20,000 reviewed advisories across ecosystems including npm, PyPI, RubyGems, Maven, Go modules, NuGet, and Composer. GHSA absorbed several ecosystem-specific databases over time — including the original Ruby Advisory Database and the PHP Security Advisories Database — consolidating what used to be a fragmented set of community-maintained feeds into one GitHub-curated pipeline. Trivy also ingests RustSec's advisory database directly for Rust crates. Because GHSA advisories go through a GitHub review step before publication, they tend to lag initial public disclosure by anywhere from a few hours to several days, which is faster than NVD's current enrichment backlog but still introduces a detection window that scan-time-only tools inherit by default.
Is kube-hunter part of Trivy's vulnerability data pipeline?
No — kube-hunter is a standalone Aqua Security open source project for active Kubernetes penetration testing, and it has no role in populating trivy-db. kube-hunter works by probing a live cluster from inside or outside the network — looking for exposed API servers, open kubelet ports, or misconfigured RBAC — and it reports live findings during that probe, not CVE records that get archived anywhere Trivy reads from. Trivy's own Kubernetes coverage (trivy k8s) is a completely different mechanism: it scans workload manifests, container images, and cluster resources against the same trivy-db vulnerability and misconfiguration data used everywhere else in Trivy. The two tools share an Aqua GitHub org and a "Kubernetes security" label, but conflating them — as the keyword phrasing sometimes implies — overstates how Trivy's CVE data actually gets built.
What gaps or lag show up in Trivy's vulnerability data today?
The two consistent gaps are refresh cadence and cross-source severity disagreement. On cadence, trivy-db itself refreshes every few hours, but that refresh can only be as current as its slowest upstream input — if NVD enrichment is backlogged or a distro tracker hasn't updated its feed, the compiled database inherits that staleness silently, with no indicator in the scan output that a given package's data might be days or weeks old. On severity, it's common for the same CVE to carry a different CVSS score or even a different "fixed" status across NVD, GHSA, and a vendor's own OVAL feed, and Trivy has to apply a fixed precedence order (generally: OS vendor advisory over NVD for distro packages, GHSA for language dependencies) to resolve the conflict — which means the score you see reflects Trivy's tie-breaking logic as much as it reflects the underlying research. Trivy's maintainers have also periodically flagged trivy-db's growing size as advisory volume increases, which affects how quickly clients can pull and load a fresh copy in CI.
How Safeguard Helps
Safeguard was built around the reality that no single upstream feed — NVD, GHSA, or a distro tracker — is complete or current on its own, and that batch-refreshed local databases like trivy-db will always carry some lag between publication and detection. Instead of compiling one static snapshot on a fixed schedule, Safeguard continuously correlates advisories across NVD, GHSA, OSV, and vendor-specific trackers as they publish, and retains the provenance of each match so a finding shows not just a CVSS score but which source it came from and when that source last confirmed it. For distro packages, Safeguard applies the same vendor-advisory-first logic that avoids Trivy's classic backport false positives, while flagging the specific cases where NVD's enrichment backlog means a CVE genuinely hasn't been triaged upstream yet — so teams can distinguish "not vulnerable" from "not yet scored." Because Safeguard treats vulnerability data as a live feed rather than a periodic rebuild, newly disclosed CVEs and updated fix-version data reach your SBOMs and running workloads without waiting on the next scheduled database compile, closing exactly the detection window that point-in-time, snapshot-based scanners like Trivy leave open by design.