When Trivy flags a "Critical" vulnerability in your container image, the CVE ID it prints is pulled from the National Vulnerability Database — but the severity score, the affected version ranges, and the fix recommendation often come from somewhere else entirely: the Aqua Vulnerability Database, or AVD. Maintained by Aqua Security since 2021, AVD is the curated backbone that powers Trivy's scan results for hundreds of thousands of organizations. Most teams running trivy image or trivy fs in CI never look past the terminal output to ask where the data actually originated, which means they inherit AVD's coverage gaps, update cadence, and scoring quirks without realizing it. Given that Trivy has become the default scanner baked into GitHub Actions, GitLab, and countless Kubernetes admission controllers, understanding AVD's design — and its blind spots — matters for anyone deciding whether one database is enough to gate a release.
What Is the Aqua Vulnerability Database (AVD)?
AVD is Aqua Security's proprietary vulnerability intelligence platform, publicly browsable at avd.aquasec.com, that aggregates and re-enriches vulnerability data from more than a dozen upstream sources — including the NVD, GitHub Security Advisories (GHSA), the Open Source Vulnerability database (OSV), Red Hat's OVAL feeds, Alpine's secdb, Debian's security tracker, and vendor-specific advisories from Amazon, Google, and Microsoft. Aqua launched AVD publicly in 2021 as a companion resource to Trivy, its open-source scanner that had already amassed tens of thousands of GitHub stars since its 2019 release. Rather than simply mirroring NVD entries, AVD's team applies manual triage to a subset of high-impact CVEs, correcting version ranges that upstream advisories get wrong and assigning Trivy-specific metadata like exploitability signals. As of 2026, AVD tracks well over 300,000 identifiers spanning CVEs, GitHub Security Advisories, and vendor-specific IDs (like RHSA- and USN- prefixes), across roughly 30 OS distributions and language ecosystems including npm, PyPI, RubyGems, Maven, Go modules, and Rust's crates.io.
How Does AVD Differ From the NVD?
AVD differs from the NVD by acting as an aggregator-plus-curator layer rather than a primary CVE issuing authority. The NVD, run by NIST, is the canonical source of record for CVE metadata and CVSS scores, but it has struggled with analysis backlogs — in February 2024, NIST publicly acknowledged a slowdown in CVE enrichment, and independent trackers found tens of thousands of published CVEs sitting in "awaiting analysis" status for months at a time during 2024 and into 2025. AVD was built partly to route around exactly this problem: when NVD enrichment lags, AVD pulls CVSS scores and affected-package data from distro maintainers (Debian, Alpine, Red Hat) or from GHSA instead, so Trivy scans don't silently go blind on unanalyzed CVEs. The tradeoff is that AVD's severity ratings for the same CVE can differ from NVD's, from Red Hat's, and from GHSA's — a package flagged "High" in one source may show as "Medium" in AVD because Aqua weighted a different upstream input as authoritative for that ecosystem.
How Does Trivy Use AVD to Scan For Vulnerabilities?
Trivy uses AVD as its default and primary vulnerability data source, downloading a compressed database snapshot (trivy-db) from Aqua's OCI-distributed registry at the start of every scan unless the cache is already fresh. This db bundle, typically refreshed every 6 hours upstream, contains the merged AVD records that Trivy's scanner engine matches against detected package versions in container layers, filesystems, and SBOMs. Because AVD packages together OS-level advisories (e.g., Alpine's secdb, Ubuntu's USN feed) with language-specific ecosystem data, Trivy can flag a vulnerable glibc package in a base image and a vulnerable lodash version in package-lock.json in a single pass, both sourced from the same underlying database. This is also why Trivy occasionally reports different results than tools built on other data sources like Grype (which defaults to Anchore's own feed, itself NVD- and GHSA-derived) for the identical image — each scanner's outcome is only as good as the freshness and curation choices baked into its backing database.
What Are AVD's Known Limitations and Gaps?
AVD's core limitation is coverage depth versus breadth: because Aqua's curation team manually reviews only a fraction of the hundreds of CVEs published daily (CVE.org logged over 40,000 new CVE IDs in 2024 alone, and volume has continued climbing into 2026), the vast majority of entries in AVD are passed through from upstream sources with limited additional validation. This means false negatives can occur when an upstream advisory itself is incomplete — for example, a GHSA entry that fails to list an affected transitive dependency version won't be corrected in AVD unless it happens to fall into Aqua's manually reviewed set. Community reports on Trivy's GitHub issue tracker have also documented delays of several days to a few weeks between a CVE's public disclosure and its appearance in a trivy-db update, particularly for less prominent ecosystems. Additionally, AVD's severity scoring can lag CVSS 4.0 adoption, and its reachability context (whether a vulnerable function is actually called by your code) is limited compared to purpose-built reachability analysis tools — Trivy's own reachability features remain comparatively early-stage relative to dedicated SCA platforms.
Why Does Database Choice Matter for Vulnerability Scanning Accuracy?
Database choice matters because two scanners can ingest the identical SBOM and produce materially different verdicts purely based on which vulnerability feed they trust as ground truth. A 2023 comparative study by Anchore found meaningful divergence in CVE counts and severity classifications between Trivy, Grype, and Snyk when scanning the same container images, driven almost entirely by differences in AVD, GHSA/NVD-derived feeds, and each vendor's proprietary enrichment. For a security team, this means a single-scanner, single-database pipeline can produce both false negatives (a real vulnerability absent from that one database) and false positives (a version range in the database that's simply wrong, triggering unnecessary remediation work). It's the reason compliance frameworks like SOC 2 and vulnerability management best practices increasingly point toward cross-referencing multiple authoritative sources rather than trusting any single scanner's default feed — especially in regulated environments where an auditor may ask why a known CVE wasn't flagged.
How Safeguard Helps
Safeguard treats no single vulnerability database, including AVD, as an unquestioned source of truth. Instead of running one scanner against one feed, Safeguard cross-references vulnerability findings across multiple authoritative sources — NVD, GHSA, OSV, distro-specific advisories, and vendor feeds — and reconciles discrepancies in severity, affected-version ranges, and disclosure timing before they ever reach an engineer's queue. When Trivy (or any AVD-backed tool) reports a CVE with a severity rating that diverges from what NVD or the upstream distro maintainer says, Safeguard surfaces that conflict explicitly rather than silently picking one number, so security teams can make an informed call instead of inheriting one vendor's curation choices by default.
Safeguard also closes the reachability gap that AVD-based scanning leaves open: rather than flagging every vulnerable package version regardless of whether the vulnerable code path is actually invoked, Safeguard's analysis prioritizes findings by real exploitability in your specific codebase, cutting through the noise of transitively-included but unreachable dependencies. For teams building on Trivy already, this doesn't mean ripping it out — Safeguard ingests existing scan results and enriches them with cross-database validation, giving you the speed of Trivy's AVD-backed scanning plus a second layer of verification that catches what a single database misses. For SOC 2 audits specifically, this cross-referencing creates a defensible paper trail showing that vulnerability decisions weren't based on one vendor's incomplete curation pass, but on a reconciled view across the industry's major vulnerability sources.
If your pipeline currently relies on Trivy or another AVD-backed scanner as its only line of defense, it's worth asking your security team a direct question: when AVD and NVD disagree on a CVE's severity, which one wins today — and does anyone find out when they do?