Two vulnerabilities can carry the identical CVSS score of 9.8 and mean completely different things for your Tuesday. One is a remote code execution flaw in a logging library that's reachable from the public internet, actively weaponized within 72 hours of disclosure, and sitting in 60% of your production containers — that was Log4Shell (CVE-2021-44228), scored 10.0 in December 2021. The other is a 9.8-rated deserialization bug in a dependency that's imported but never called, air-gapped behind three internal services, with zero recorded exploitation attempts in the two years since publication. Treat both the same way and you either burn your engineering week patching something no attacker will ever reach, or you miss the one that's already being scanned for on Shodan. Every AppSec platform claims to solve this with "risk scoring," but the models underneath — CVSS, EPSS, SSVC, and a dozen proprietary blends — measure fundamentally different things. Here's how they actually differ, and where each one breaks down.
What Does a CVSS Score Actually Measure?
CVSS measures theoretical severity, not real-world risk — it answers "how bad could this be if exploited" without ever addressing "will it be." The Common Vulnerability Scoring System, now on version 3.1 (released June 2019, with v4.0 following in November 2023), scores vulnerabilities from 0 to 10 based on static attributes: attack vector, complexity, privileges required, and impact on confidentiality, integrity, and availability. It never accounts for whether exploit code exists, whether the vulnerable function is reachable in your codebase, or whether anyone has ever attacked it in the wild. That's why CVSS produces so much noise: Cyentia Institute's analysis of over 200,000 published CVEs found that fewer than 4% are ever observed being exploited, yet more than half of all CVEs in the NVD are scored 7.0 or higher ("High" or "Critical"). If your platform's risk model stops at CVSS, you're triaging by a coin that's weighted toward "urgent" almost every time it lands — which is exactly how alert fatigue sets in.
How Is EPSS Different From CVSS?
EPSS predicts the probability a vulnerability will actually be exploited in the next 30 days, using real telemetry instead of static attributes — a fundamentally different question than CVSS asks. The Exploit Prediction Scoring System, maintained by FIRST.org, outputs a percentage (0-100%) derived from a machine learning model trained on exploitation data from honeypots, intrusion detection systems, and dark web chatter. EPSS v3, released in March 2023, improved accuracy substantially: FIRST reported that the v3 model captured 82% of exploited vulnerabilities within the top 50 EPSS-ranked CVEs, versus roughly 62% for v2. For Log4Shell, EPSS scored the exploitation probability above 97% within days — CVSS never moves once assigned, but EPSS is recalculated daily as attacker behavior shifts. The catch: EPSS tells you what's likely to be exploited across the entire internet, not whether your specific deployment is exposed. A CVE with a 95% EPSS score sitting in code your application never executes is still a non-issue for you, which is why platforms that stop at EPSS still generate false urgency.
What Is SSVC, and Why Are Platforms Moving to Decision Trees?
SSVC replaces a single numeric score with a branching decision tree that outputs an action — Track, Track*, Attend, or Act — rather than a number to argue about. The Stakeholder-Specific Vulnerability Categorization framework was developed by Carnegie Mellon's CERT/CC starting in 2019, and CISA formally adopted a customized version in 2022 to prioritize its Known Exploited Vulnerabilities (KEV) catalog, which as of mid-2026 lists over 1,300 CVEs confirmed as actively exploited. SSVC asks a sequence of context-specific questions: Is exploitation automatable? Is the affected component mission-critical? What's the technical impact if exploited? Because the inputs vary by organization — a hospital's SSVC path for a patient-data-adjacent CVE looks nothing like a marketing SaaS company's path for the same CVE — two teams can legitimately reach different, correct answers from the same vulnerability. This is the model's strength and its adoption barrier: it requires organizations to actually define their own asset criticality and mission impact, work that a single CVSS number lets you skip (badly).
How Do Vendor Priority Scores Like Snyk's and Mend's Combine These Inputs?
Commercial platforms build proprietary composite scores that blend CVSS, EPSS, exploit maturity, and business context into a single number, and the exact weighting is almost never fully disclosed. Snyk's Priority Score runs 0-1000 and factors in CVSS, EPSS-like exploit maturity data, whether a fix is available, and social signals like security researcher chatter. Mend (formerly WhiteSource) layers its own "Effective Usability Analysis" reachability signal on top of CVSS to suppress findings in unused code paths. Black Duck and Veracode both publish ordinal risk tiers that mix CVSS severity with license risk and, in Veracode's case, a proprietary flaw-density benchmark against comparable applications. GitHub's Dependabot, by contrast, still leans almost entirely on the GitHub Security Advisory database's CVSS-derived severity, which is one reason security teams report Dependabot backlogs numbering in the thousands per repository — a 2024 GitHub Octoverse survey found the average enterprise repo carries over 500 open Dependabot alerts, most never triaged. The practical difference for buyers: two platforms scanning the same codebase can rank the same CVE in opposite priority tiers, because one weights exploit prediction heavily and the other weights business-tagged asset criticality. Ask any vendor for their scoring methodology in writing before you standardize workflows around their number — "proprietary algorithm" is not an acceptable answer when it's driving your patch SLAs.
Why Does Reachability Analysis Change the Score Entirely?
Reachability analysis determines whether the vulnerable function in a dependency is actually called by your code, and it can eliminate 70-90% of flagged vulnerabilities as non-actionable in a typical codebase. This is the single biggest divergence point between platforms. A CVE in a transitively-included dependency — say, a vulnerable XML parser three layers deep in your dependency tree — only matters if your application's code path ever invokes the vulnerable function with attacker-controllable input. Static reachability analysis (used by tools like Semgrep Supply Chain and increasingly by Snyk and Mend) traces the call graph from your application entry points down through the dependency tree to confirm whether that path exists. Endor Labs published data in 2023 showing that reachability filtering cut actionable open-source vulnerabilities by roughly 85% across the codebases they analyzed, without missing genuinely exploitable issues. Platforms without reachability analysis are effectively scoring the entire npm or Maven registry's risk profile and hoping CVSS or EPSS narrows it down — but neither signal knows what your code actually executes. This is also why NVD's 2024 enrichment slowdown mattered so much: after February 12, 2024, NVD fell behind on CVSS scoring for new CVEs, and by May 2024 had analyzed only a small fraction of the backlog, leaving platforms that depend solely on NVD-sourced CVSS scores with an incomplete picture for months.
How Safeguard Helps
Safeguard doesn't ask you to pick a single scoring model — it correlates CVSS, EPSS, KEV status, and static reachability into one risk view so your team acts on exposure, not on whichever number a single vendor happened to compute. Every finding in Safeguard is checked against whether the vulnerable code path is actually reachable from your application's entry points before it's surfaced as actionable, which is how teams using Safeguard typically see their open critical/high vulnerability count drop by the majority in the first triage pass — not because the vulnerabilities disappeared, but because the noise did. Where CISA's KEV catalog or FIRST's EPSS feed indicates active exploitation, Safeguard escalates automatically regardless of the underlying CVSS score, so a "medium severity" CVE with confirmed in-the-wild exploitation doesn't sit behind a queue of unreached 9.8s. And because Safeguard exposes the full scoring breakdown — CVSS vector, EPSS percentage and trend, KEV status, and reachability verdict — for every finding, your security team can build SLAs and audit evidence around a documented methodology instead of a black-box number, which matters as much for SOC 2 and customer security questionnaires as it does for your own triage queue. The result isn't a new score to trust blindly; it's the context to know when any score — yours or a vendor's — is worth acting on.