A mid-size fintech engineering team runs trivy image against their production API container on a Tuesday morning in March. The scan comes back with 1,847 findings — 412 marked CRITICAL or HIGH. The on-call security engineer has four hours before the daily deploy freeze lifts. She cannot triage 1,847 line items by hand, so she does what almost every team in this position does: she sorts by CVSS score, patches the top 20, and closes the ticket. Two months later, one of the "LOW" severity findings she skipped — a deserialization bug in a logging library — turns up in an incident postmortem. This is not a story about one bad scanner. It's the default outcome of running any vulnerability scanner, including Aqua's Trivy, without a layer that tells you which findings actually matter. Here's why that happens, and what fixes it.
Why Do Vulnerability Scanners Produce So Many False Positives?
Because scanners like Trivy match package names and versions against CVE databases without checking whether the vulnerable code path is ever loaded, called, or reachable from your application. Trivy is excellent at what it's built to do: it cross-references OS packages (via distro advisory feeds like Debian's DSA or Alpine's secdb) and language-level manifests (package-lock.json, go.sum, requirements.txt) against known-CVE lists, and it does this fast — a typical scan of a 500MB image completes in under 30 seconds. But matching a version string to a CVE identifier isn't the same as confirming exploitability. A 2023 analysis by the Cyentia Institute found that only 2–7% of published CVEs have ever had exploitation observed in the wild, yet vendor scanners routinely flag every version-matched CVE at face value. If your base image ships a vulnerable OpenSSL version that's compiled in but never invoked by your app's code paths, Trivy will still surface it as CRITICAL.
Does a High CVSS Score Actually Mean a Vulnerability Is Urgent?
No — CVSS measures theoretical severity, not real-world risk, and treating it as a priority queue is the single biggest driver of alert fatigue. CVSS v3.1 base scores are calculated from static factors (attack vector, complexity, privileges required) that don't account for whether the vulnerable function is reachable, whether a public exploit exists, or whether the asset is internet-facing. That's why FIRST.org built EPSS (Exploit Prediction Scoring System) as a companion metric: as of the March 2024 EPSS model update, fewer than 1,300 of the roughly 240,000+ CVEs in the NVD are also listed in CISA's Known Exploited Vulnerabilities (KEV) catalog — meaning over 99% of tracked CVEs have no confirmed real-world exploitation. Yet CVSS-only triage (Trivy's default sort order) puts a 9.8-scored CVE in an unused test dependency ahead of a 7.2-scored CVE with an active Metasploit module. Teams that triage by CVSS alone are optimizing for the wrong signal.
How Much Time Do Security Teams Actually Lose to Noisy Scan Results?
A significant and measurable amount — industry surveys consistently put the number at multiple full workdays per week per analyst. A 2023 Ponemon Institute study on SOC operations found that the average security team receives over 4,000 alerts per day across their tooling stack and spends roughly 25% of analyst time chasing alerts that turn out to be false positives or low-priority noise. In vulnerability management specifically, this manifests as the "CVE backlog" problem: NVD's own analysis backlog, which began in February 2024 when the agency slowed its enrichment pipeline, left tens of thousands of CVEs without CPE (Common Platform Enumeration) matching or CVSS scoring for months — meaning scanners either under-report newly published CVEs or over-report by falling back to conservative worst-case severity. Either failure mode pushes more unverified findings onto the same overloaded human queue.
Why Does Trivy Flag CVEs in Dependencies That Never Execute?
Because Trivy performs manifest-based (also called "presence") scanning rather than reachability analysis, so it has no visibility into your application's actual call graph. If your package-lock.json includes lodash as a transitive dependency of a build tool, and a CVE is published against a lodash function you never call in production, Trivy will still list it — because the version string is present in the lockfile, full stop. This isn't a flaw unique to Trivy; it's true of Grype, Snyk Open Source, and most SCA tools that operate at the manifest layer. The practical effect: research from multiple SCA vendors (including Snyk's own 2022 State of Open Source Security report) has estimated that 60–80% of dependencies flagged in a typical scan are never loaded at runtime in the deployed application. For a team drowning in a 400-finding report, knowing which subset is even loaded into memory would immediately cut the list by more than half.
What Would It Take to Cut Alert Volume Without Missing Real Risk?
It requires layering exploitability and reachability context on top of raw CVE matches, not just adjusting severity thresholds. Simply raising Trivy's --severity flag to only show CRITICAL,HIGH is a common workaround, but it's a blunt instrument — teams using severity-only filtering have shipped known-exploited vulnerabilities rated MEDIUM (the 2021 log4j-adjacent CVEs are a well-documented example of initially under-scored issues later escalated after real-world exploitation was confirmed). The fix that actually reduces volume while preserving coverage combines three signals scanners like Trivy don't natively provide: (1) code-level reachability — is the vulnerable function in the call path, (2) exploit intelligence — is there a KEV listing, EPSS score above ~0.1, or public PoC, and (3) deployment context — is this asset internet-facing, does it handle sensitive data, is it in a production namespace. Teams that layer all three typically report cutting actionable findings by 85–95% relative to raw scanner output, according to benchmarks published by several ASPM vendors in 2023–2024.
How Safeguard Helps
Safeguard is built to sit on top of scanners like Trivy rather than replace the detection layer they're good at — you keep the fast, broad CVE matching Aqua's tooling already does well, and Safeguard adds the triage layer that turns 1,800 raw findings into the 30–50 that actually need a human decision this week.
Concretely, Safeguard ingests Trivy's SBOM and scan output directly (no re-scanning, no duplicate pipeline step) and immediately cross-references every finding against CISA KEV, live EPSS scores, and public exploit availability. Findings with no exploitation evidence and no reachable code path get automatically deprioritized — not deleted, just moved out of the interrupt-driven queue and into a scheduled backlog review. Findings that are reachable, exploited in the wild, and sitting on an internet-facing service get escalated to the top with the supporting evidence attached, so the engineer opening the ticket doesn't have to re-derive "why does this matter" from scratch.
Safeguard also tracks vulnerability lifecycle across your fleet: if the same CVE shows up in 40 container images because they all inherit from the same base image, Safeguard groups that into a single fix-once ticket (rebuild the base image, redeploy) instead of 40 separate alerts landing in 40 separate team queues. This is the deduplication step that manifest-based scanners have no concept of, because each scan runs in isolation.
Finally, Safeguard gives security leaders a defensible metric for what "done" looks like — mean time to remediate for reachable, exploited, internet-facing CVEs, tracked separately from the long tail of low-risk findings that can sit in a quarterly cleanup pass. That distinction is what turns alert fatigue cybersecurity metrics from a vague morale problem into a measurable, shrinking number. Teams that adopt this triage layer alongside their existing Trivy pipeline typically see their weekly "must-fix-now" list drop from hundreds of items to single digits within the first scan cycle — not because the underlying risk changed, but because the noise finally got filtered out before it reached a human.
If your team is running Trivy, Grype, or another SCA scanner and still burning entire sprints on vulnerability triage, the scanner isn't the problem — the missing prioritization layer is. That's the gap Safeguard closes.