Security teams don't have a vulnerability problem — they have a volume problem. A mid-size engineering org scanning a few hundred container images can easily surface 8,000-15,000 open CVEs on any given day, and if every "Critical" or "High" finding triggers a ticket, the backlog grows faster than any team can burn it down. CVSS was built in 2005 to describe technical severity, not to answer the question security teams actually ask: what do we fix today? A CVSS 9.8 score doesn't tell you whether the vulnerable function is ever called, whether the package is reachable from the internet, or whether anyone is exploiting it in the wild. Open-source scanners like Trivy do an excellent job finding vulnerabilities and mapping them to CVSS severity — but severity alone still leaves teams triaging thousands of findings with no real signal on exploitability or business impact. This is where prioritization frameworks built on reachability, exploit data, and runtime context take over.
Why Isn't a CVSS 9.8 Score Enough to Decide What to Fix First?
Because CVSS measures theoretical worst-case severity, not real-world exploitability, and the two rarely correlate the way teams assume. Research from the Cyentia Institute and Kenna Security, tracking exploitation data across hundreds of thousands of CVEs, has repeatedly found that only around 2-5% of published vulnerabilities are ever observed being exploited in the wild — yet roughly a third of all CVEs are scored High or Critical (7.0+). That mismatch means a team that triages strictly by CVSS is spending most of its remediation effort on vulnerabilities that were never going to be attacked, while genuinely dangerous but lower-scored issues slip through. CVE-2023-4863, a heap buffer overflow in the libwebp image library, was scored 8.8 (High, not even Critical) — yet it was an actively exploited zero-day used in real spyware campaigns against Apple and Google users in September 2023, patched urgently by both vendors within days. A severity-only queue would have ranked it behind dozens of "Critical" findings nobody was actually using.
What Happened When NVD Fell Behind on Scoring in 2024?
In February 2024, the National Vulnerability Database publicly acknowledged it had drastically slowed its CVE enrichment — the process that assigns CVSS vectors, CWE mappings, and affected-product data to new CVE entries. By mid-2024, NVD had a backlog of more than 20,000 CVEs awaiting analysis, some sitting unscored for months after publication, even as the total volume of disclosed CVEs kept climbing past 40,000 for the year. Any tool or process that depends on NVD's CVSS score as its primary prioritization signal was, for large stretches of 2024, effectively blind on a fifth of the CVE catalog. Teams that had built triage workflows entirely around "wait for the NVD score, then rank" discovered in real time why a single upstream data source is a fragile foundation for prioritization — and why exploit-intelligence feeds that don't depend on NVD's enrichment pipeline became more valuable almost overnight.
How Do EPSS and CISA's KEV Catalog Change the Prioritization Math?
They replace "how bad could this be" with "how likely is this to be exploited right now," and the difference in output is dramatic. EPSS (Exploit Prediction Scoring System), maintained by FIRST.org, assigns each CVE a daily-updated probability of exploitation within the next 30 days based on observed scanning and exploit activity — and its own validation data shows that CVEs above the 0.36 EPSS threshold capture the vast majority of real-world exploitation activity while representing a small fraction of total CVE volume. CISA's Known Exploited Vulnerabilities (KEV) catalog is even blunter: as of 2025 it lists roughly 1,300 CVEs confirmed to have been exploited in the wild, out of more than 240,000 CVEs ever published — well under 1% of the total. A team that reprioritizes its backlog around EPSS score and KEV membership instead of raw CVSS routinely cuts its "must-fix-now" list by 90% or more, without meaningfully increasing residual risk, because it's now ranking by evidence of attacker behavior instead of a static severity guess made at disclosure time.
Does Reachability Analysis Actually Reduce Noise?
Yes, and often more aggressively than exploit-intelligence feeds alone, because it answers a question EPSS and KEV can't: does your specific build ever execute the vulnerable code path? A container image can bundle a language runtime, an OS base layer, and forty transitive dependencies, but a typical application only calls a small percentage of the functions those packages expose. Static reachability analysis — tracing your application's actual call graph against the vulnerable function or code path identified in an advisory — routinely finds that 60-80% of flagged CVEs in transitive dependencies are in code that is never invoked at runtime. Log4Shell (CVE-2021-44228), disclosed December 9, 2021 with a CVSS score of 10.0, is the canonical counter-example: it was both reachable and trivially exploitable via a single crafted string in log input, which is exactly why it triggered emergency patching across the industry within 72 hours. The point of reachability isn't to dismiss every Critical finding — it's to separate the Log4Shells from the thousands of CVEs sitting in unreachable code that pose functionally zero risk to your specific deployment.
Where Does Trivy Fit — and Where Does It Stop?
Trivy, Aqua Security's open-source scanner, is genuinely good at what it's designed to do: fast, broad detection of known vulnerabilities across container images, filesystems, and git repositories, mapped to CVSS-based severity buckets (Critical/High/Medium/Low/Unknown) pulled from its Trivy DB advisory sources. Since version 0.45 (released in 2023), Trivy also supports VEX (Vulnerability Exploitability eXchange) documents, letting teams manually attach "not affected" statements to suppress specific findings. But that VEX support is manual by default — someone still has to research and author the statement for each CVE-package combination — and Trivy's core CLI output has no built-in reachability analysis, no EPSS or KEV enrichment, and no runtime or asset-criticality context. Two identical Trivy scans of the same base image, deployed to an internet-facing payment service versus an internal batch job, will produce identical severity output, even though the real-world risk is nowhere close to equal. Trivy tells you what's there; it was never built to tell you what matters.
How Safeguard Helps
Safeguard is built specifically to close the gap between "here's a list of CVEs" and "here's what to fix this week." Rather than treating CVSS as the final word, Safeguard correlates every finding against multiple live signals — EPSS exploitation probability, CISA KEV membership, public exploit availability, and static reachability analysis against your actual application call graph — and rolls them into a single prioritized risk score per finding. That means a Critical CVSS 9.8 in an unreachable transitive dependency gets automatically deprioritized below a Medium-severity, KEV-listed vulnerability sitting in a reachable, internet-facing service.
Safeguard also layers in runtime and business context that generic scanners can't see on their own: whether the affected artifact is actually deployed, whether the service is internet-facing, and how critical the asset is to the business, so two instances of the same CVE in different environments can land in very different queues. For teams already running Trivy or similar scanners in CI, Safeguard ingests those SBOM and scan results directly rather than requiring a rip-and-replace, layering prioritization, reachability, and exploit intelligence on top of existing tooling. The result teams typically report is a 80-95% reduction in "actionable" tickets compared to raw severity-based triage, with the remaining findings backed by evidence — EPSS score, KEV status, and a reachable call path — that makes the case for fixing them self-evident to both engineers and auditors. For organizations under SOC 2 or similar compliance pressure, that evidence trail also becomes the documentation auditors ask for when they want proof that vulnerability management is risk-based rather than checkbox-driven.