Open a random CI pipeline at a mid-size engineering org today and there is a good chance trivy image or trivy fs is one of the steps. Trivy, the open-source scanner built and maintained by Aqua Security, has become the default way teams find CVEs in container images, filesystems, IaC templates, and SBOMs — it is free, fast, and easy to drop into a GitHub Action. But "easy to add" and "sufficient for supply chain security" are different claims. Aqua built Trivy as the funnel into its commercial CNAPP, and the gap between the two is where a lot of production risk quietly accumulates: stale databases, alert floods with no prioritization, and no audit trail for SOC 2 auditors asking how vulnerabilities get triaged. This post breaks down what Trivy actually does, where it came from, what it misses, and how Safeguard closes that gap without asking you to rip it out.
What is Trivy and who actually maintains it?
Trivy is an open-source vulnerability and misconfiguration scanner originally released by Aqua Security engineer Teppei Fukuda (knqyf263) in 2019, and it is still Aqua that funds and directs its core development. It scans container images, filesystems, git repositories, Kubernetes clusters, and Infrastructure-as-Code files (Terraform, CloudFormation, Dockerfile, Kubernetes manifests) for known CVEs, exposed secrets, license issues, and misconfigurations, and it can generate SBOMs in CycloneDX or SPDX format. In September 2022, Trivy joined the CNCF Sandbox, which gave it a neutral governance story even though Aqua remains the primary maintainer and largest contributor by commit volume. In late 2023, Aqua folded its separately acquired IaC scanner, tfsec, directly into Trivy and archived the standalone tfsec repository, consolidating Aqua's open-source scanning story into a single Apache 2.0-licensed binary. That consolidation is worth noting: Trivy isn't a community project that happens to be popular, it's Aqua's top-of-funnel product, engineered to be good enough to get you comfortable with Aqua's detection logic before you ever look at a paid tier.
How does Trivy compare to Aqua Security's paid platform?
Trivy answers "what CVEs exist in this artifact right now," while Aqua's commercial CNAPP answers "what should I do about it across my whole environment, continuously." Aqua Security, founded in 2015 and valued at over $1 billion after a $135 million Series E round in March 2021, sells Trivy's detection engine wrapped in the things a free CLI can't provide: centralized policy enforcement across repos and clusters, Dynamic Threat Analysis sandboxing for behavioral malware detection, runtime protection, drift detection, and research from its Team Nautilus threat unit (the group that publicly disclosed attacks like Denonia, a cryptomining worm targeting AWS Lambda, and Siloscape, targeting Windows containers). None of that ships in the open-source CLI. Trivy will happily print 400 CVEs for a single python:3.9-slim image scan and leave you to decide which ones matter — that triage layer is exactly what Aqua, and every commercial vendor built on top of Trivy's database, charges for.
What does Trivy actually miss in a production pipeline?
Trivy misses continuous monitoring, cross-team policy enforcement, and exploitability context — it tells you a CVE exists, not whether it's reachable or actively exploited. A scan is a snapshot: run trivy image myapp:latest on Tuesday and a new CVE published Wednesday (NVD publishes several hundred new CVEs most weeks) sits undetected until someone reruns the scan. Trivy also has no native concept of EPSS scores or CISA's Known Exploited Vulnerabilities (KEV) catalog, so a CVSS 9.8 in a library your application never calls gets the same visual weight as one sitting in an internet-facing entry point. Teams that wire Trivy into CI without a downstream layer routinely end up with severity-only gating — block on "Critical," ignore everything else — which both lets exploitable Medium-severity issues through and burns engineering time triaging Criticals that are unreachable at runtime. Trivy also has no built-in ticketing, ownership routing, or SLA tracking, so "who owns this CVE and by when does it need fixing" becomes a spreadsheet problem in most orgs within a quarter of adoption.
What happened when Trivy's vulnerability database hit rate limits?
In early 2023, Trivy users started seeing CI pipelines fail with 429 "rate limit exceeded" errors when pulling the trivy-db vulnerability feed from GHCR, because Trivy distributes its database as an OCI artifact and shared IP ranges on GitHub Actions runners and other CI providers collided with GitHub Container Registry's anonymous pull limits. This wasn't a hypothetical edge case — it broke real release gates, since Trivy fails closed (or silently scans with a stale cached DB, depending on configuration) when it can't fetch the latest feed. The incident is a useful case study in why a single open-source binary run in isolation is a fragile control: the same team that maintains the scanner also controls the distribution channel for its ground truth data, and a shared-infrastructure hiccup on their side becomes a security-gate outage on yours. Teams running Trivy at scale ended up self-hosting mirrors of trivy-db or paying for authenticated registry access just to keep their own pipelines green — infrastructure work that has nothing to do with actually reducing vulnerability risk.
Is Trivy enough to satisfy SOC 2 or customer security questionnaires?
No — Trivy gives you scan output, not the evidence trail auditors and enterprise customers actually ask for. A SOC 2 Type II auditor evaluating your vulnerability management control wants to see a documented triage process, defined remediation SLAs by severity, proof that findings were tracked to closure, and role-based access showing who can override or accept risk on a given CVE. Trivy's JSON or SARIF output has none of that built in: there's no persistent record of "this Critical was accepted as risk on 2026-03-14 by [name] because it's unreachable code," no historical trend of mean-time-to-remediate, and no way to prove to a customer's security team that findings from six months ago were actually resolved rather than just scrolled past in a CI log. Companies that rely on Trivy alone typically end up building a homegrown Postgres table and a Slack bot to reconstruct this evidence trail during audit season — a scramble that's avoidable with a system designed around the compliance workflow from the start.
How Safeguard Helps
Safeguard doesn't ask you to abandon Trivy — it sits on top of it and every other scanner in your stack (Trivy, Grype, Snyk, npm audit, and language-native tooling) as the aggregation, prioritization, and evidence layer that the open-source binary was never built to be. Findings from Trivy scans flow into Safeguard where they're deduplicated across images, repos, and clusters, then re-ranked using exploitability signals — EPSS score, CISA KEV membership, and actual reachability analysis — so a team isn't burning a sprint chasing a Critical CVE in a dependency that's never invoked. Safeguard maintains its own vulnerability intelligence pipeline, independent of any single vendor's database availability, so a distribution hiccup on someone else's registry doesn't fail your release gate the way the 2023 trivy-db rate-limit incident did. Every finding gets an owner, an SLA based on your organization's policy, and a permanent audit record — acceptances, exceptions, and remediation timestamps — generated automatically for SOC 2 Type II evidence and customer security questionnaires, so audit season stops being a Slack-and-spreadsheet scramble. And because Safeguard is built for software supply chain security specifically, it correlates vulnerability data with SBOM provenance and build integrity signals, giving you the "what's actually risky and reachable" answer that Trivy's raw scan output, and Aqua's own upsell path, are both designed to leave you to figure out on your own.