In 2024, the National Vulnerability Database logged more than 40,000 new CVEs — roughly 110 every single day — while the security team at a typical mid-sized SaaS company might realistically close out 50 to 100 vulnerabilities a week. Do that math over a year and the backlog only grows. Scanners like Trivy, Aqua Security's open-source tool, do an excellent job finding vulnerabilities across container images, IaC, and SBOMs, but by default they sort results by CVSS severity — a scoring system built in 2005 to describe technical impact, not real-world exploitability. The result: thousands of "Critical" and "High" findings, most of which will never be exploited, competing for the same two overworked engineers' attention. Risk-based vulnerability management (RBVM) exists to close that gap, combining exploit intelligence, exposure context, and business impact so teams fix the handful of vulnerabilities that actually matter first. Here's how it works, why severity-only triage falls short, and where Safeguard fits in.
What Is Risk-Based Vulnerability Management?
Risk-based vulnerability management is the practice of prioritizing remediation using exploitability and exposure data alongside — or instead of — a single severity score, so teams fix the vulnerabilities most likely to be attacked rather than the ones with the scariest-looking number. Gartner popularized the term around 2018 as vendors moved beyond raw CVSS sorting, and by 2021 it had become a standard line item in vulnerability management RFPs.
In practice, RBVM pulls in four kinds of signal: exploit maturity (is there a working exploit or proof-of-concept), active exploitation (is it being used in real attacks right now), exposure (is the vulnerable component actually reachable from the internet or invoked by running code), and business context (does this asset sit in front of customer data, or is it a dev sandbox nobody uses). A CVSS 9.8 vulnerability in an unreachable library on an internal test cluster is, in practical risk terms, less urgent than a CVSS 6.5 vulnerability in an internet-facing API with a known exploit circulating on GitHub. Severity alone can't tell those two apart. Risk-based scoring can.
Why Isn't CVSS Severity Alone Enough to Prioritize Vulnerabilities?
CVSS severity alone isn't enough because it measures theoretical technical impact, not the probability that a given vulnerability will actually be exploited, and those two things correlate poorly in practice. The Cyentia Institute's "Prioritization to Prediction" research, run in partnership with Kenna Security across several years starting in 2019, found that only around 2-5% of published CVEs are ever observed being exploited in the wild — yet CVSS labels roughly 60% of all CVEs as "High" or "Critical." If a team tries to patch every High/Critical finding, it's chasing a false signal for the overwhelming majority of its work.
The problem compounds because CVSS itself changed shape multiple times — version 3.1 shipped in 2019 and CVSS 4.0 arrived in November 2023 — while the underlying score still describes worst-case technical severity assuming an attacker can already reach the flaw. It says nothing about whether an exploit exists, whether it's being used, or whether your specific deployment even calls the vulnerable function. Teams that scan with CVSS-only tooling routinely report finding 1,000+ open "Critical" vulnerabilities in a single container registry, a number so large it guarantees most will sit untouched, including the few that genuinely matter.
How Does Trivy Handle Vulnerability Prioritization?
Trivy handles prioritization the way most open-source scanners do: it reports CVSS severity and vendor-published fix versions, and leaves the actual risk-scoring work to the user. Trivy, maintained by Aqua Security, is a genuinely strong scanner — it covers container images, filesystems, Git repositories, Kubernetes manifests, Terraform, and SBOMs in formats like CycloneDX and SPDX, and it's fast enough to run in CI on every pull request. Its default report buckets findings into UNKNOWN/LOW/MEDIUM/HIGH/CRITICAL straight from the NVD or vendor advisory.
Aqua has added useful refinements over time — Trivy gained VEX (Vulnerability Exploitability eXchange) support in 2023, letting teams suppress CVEs a vendor has explicitly marked "not affected," and Aqua's commercial platform layers additional context like runtime and network exposure on top of the open-source scan. But out of the box, Trivy itself doesn't compute an EPSS-style exploit-probability score, doesn't cross-reference CISA's Known Exploited Vulnerabilities catalog, and doesn't perform reachability analysis to confirm whether flagged code paths actually execute. Teams running Trivy standalone typically end up building a separate spreadsheet, Jira automation, or in-house scoring script just to turn the raw scan output into a triage order — exactly the manual step RBVM is meant to eliminate.
What Data Should Risk-Based Prioritization Actually Use?
Effective risk-based prioritization pulls from at least three data sources beyond CVSS: EPSS, CISA's KEV catalog, and reachability/exposure analysis. EPSS (Exploit Prediction Scoring System), maintained by FIRST.org, produces a daily-updated probability — a score from 0 to 1 — estimating the likelihood a given CVE will be exploited in the next 30 days; EPSS v3, released in March 2023, is trained on real observed exploitation data from sources like GreyNoise and Shadowserver. A CVE sitting at EPSS 0.02 (2% chance) can reasonably wait; one at EPSS 0.80 cannot.
CISA's Known Exploited Vulnerabilities catalog, established in November 2021 under Binding Operational Directive 22-01, lists CVEs with confirmed active exploitation and has grown past 1,300 entries by 2025. Anything on the KEV list is, by definition, no longer theoretical — it's being used against real targets today, and federal agencies are bound by fixed remediation deadlines (often 2-3 weeks) once a CVE lands on it. Layer in reachability analysis — does a call graph show the vulnerable function is actually invoked, and is the containing service internet-facing or internal-only — and the difference in outcome is stark. In a representative enterprise container fleet, a raw scan might surface 1,200+ CVEs; filtering by KEV membership, EPSS above a threshold like 0.10, and confirmed reachability typically narrows that list to somewhere between 15 and 40 items — a 95%+ reduction in remediation workload with no increase in actual risk exposure.
How Do You Operationalize Risk-Based Vulnerability Management?
You operationalize RBVM by building a pipeline — not a spreadsheet — that ingests raw scanner output, enriches it automatically with exploit and exposure data, and routes only top-tier findings into ticketing with real SLAs. Concretely, that means: run the scanner (Trivy, Grype, or a commercial equivalent) on every build; pipe results through an enrichment layer that attaches current EPSS scores, checks KEV membership, and confirms reachability against the built artifact; apply a scoring policy that weights exploit likelihood, exposure, and asset criticality (a common approach assigns 40% to exploit data, 30% to exposure, 30% to asset tier); and auto-file only the findings above a risk threshold, with SLA clocks that vary by tier — say, 48 hours for anything KEV-listed and internet-facing, 30 days for everything else that clears the bar, and no ticket at all for the rest.
The gap between "found" and "fixed" is where most vulnerability management programs actually fail. A 2023 Ponemon/IBM study on the state of vulnerability management put average time-to-remediate for critical vulnerabilities at over 60 days industry-wide — not because teams lack scanners, but because undifferentiated backlogs make it impossible to know where to start. Cutting the actionable list from 1,200 to 20 doesn't just save engineering time; it's the difference between a program that closes its riskiest gaps in days and one that closes them, if ever, months after the fact.
How Safeguard Helps
Safeguard is built around the premise that a vulnerability finding is only useful once it's scored against real-world context, not just plotted on the CVSS scale. Where a Trivy scan hands you a severity-sorted list, Safeguard automatically enriches every finding with live EPSS scores, CISA KEV status, and reachability analysis against your actual build artifacts and SBOMs — so a "Critical" CVE in a dependency your code never calls gets ranked below a "Medium" one that's actively being exploited against internet-facing services.
That enrichment plugs directly into CI/CD as a policy gate: teams set thresholds (for example, block merges on any KEV-listed, reachable, internet-facing finding; warn-only on everything else) instead of drowning developers in every CVE a scanner surfaces. Safeguard's exposure graph maps each vulnerability to the specific service, its network reachability, and its data sensitivity, so the same CVE can carry a different priority in a customer-facing payments service than in an internal admin tool. Findings route into Jira or Slack with SLA timers already attached to their risk tier, and dashboards track mean-time-to-remediate by tier so security and engineering leadership can see whether the program is actually closing the vulnerabilities that matter — not just shrinking a raw count.
For teams already running Trivy or another open-source scanner, Safeguard doesn't require ripping anything out: it ingests existing scan output and SBOMs, layers risk-based prioritization on top, and turns a 1,000-item CVE backlog into a short, defensible, and genuinely urgent list.