Security teams drowning in vulnerability alerts have learned the hard way that a single number rarely tells the whole story. A package might carry a "Critical" CVSS score and still sit safely unreachable in production code, while a "Medium" finding tied to active exploitation in the wild demands attention today. CVE, CVSS, EPSS, and SSVC each answer a different question — what the flaw is, how severe it could be, how likely it is to be exploited, and what action to take — and conflating them is one of the most common reasons remediation backlogs never shrink. This matters even more in software supply chain security, where a single vulnerable transitive dependency can fan out into thousands of alerts across a monorepo. Safeguard and Socket.dev both sit in this space, but they lean on these scoring systems differently. This post breaks down what each standard actually measures, where CVSS and EPSS diverge, how SSVC changes the decision model entirely, and how Safeguard's approach to prioritization compares to Socket.dev's.
What Do CVE, CVSS, EPSS, and SSVC Actually Measure?
These four terms get used interchangeably in vendor marketing, but they are not substitutes for one another — they're layers.
- CVE (Common Vulnerabilities and Exposures) is an identifier, not a score. Maintained by MITRE, it's simply a standardized way to name a specific known flaw (e.g., CVE-2024-XXXXX) so different tools and teams can talk about the same issue.
- CVSS (Common Vulnerability Scoring System), maintained by FIRST, produces a 0–10 severity score based on technical characteristics of the flaw itself: attack vector, complexity, privileges required, and impact on confidentiality, integrity, and availability. Critically, CVSS Base scores describe theoretical severity — they say nothing about whether the vulnerability is being exploited anywhere.
- EPSS (Exploit Prediction Scoring System), also maintained by FIRST, produces a 0–100% probability estimate of a vulnerability being exploited in the wild in the next 30 days. It's a statistical model trained on real-world exploitation telemetry, not a judgment about theoretical severity.
- SSVC (Stakeholder-Specific Vulnerability Categorization), developed by CISA and the CERT/CC, isn't a score at all — it's a decision tree. It takes inputs like exploitation status, technical impact, and mission/well-being consequences, and outputs an action: Track, Track*, Attend, or Act.
Understanding this hierarchy is the foundation for any sane vulnerability management program, and it's the lens through which the rest of this comparison should be read.
Why CVSS Alone Isn't Enough for Prioritization
CVSS was never designed to be a prioritization engine, yet for years it became the default one because it was the only widely available number. The problem is well documented: research from Kenna Security, Cyentia, and FIRST itself has repeatedly shown that CVSS severity correlates weakly with actual exploitation. A large share of vulnerabilities scored 9.0+ are never exploited, while some scored in the 4–6 range are actively weaponized within days of disclosure.
For software supply chain security specifically, this gap is amplified. A dependency scanner that surfaces every CVE above a CVSS threshold — say, "flag anything 7.0+" — will bury engineering teams in thousands of findings, most of which are dead code paths, dev-only dependencies, or flaws in functions the application never calls. Teams that triage purely on CVSS severity end up either drowning in noise or, worse, tuning their thresholds so high that real exploited issues slip through alongside the noise.
CVSS vs EPSS Scoring: Severity vs Likelihood
This is the comparison most teams are actually searching for, and it's worth being precise about it: CVSS and EPSS answer different questions, so pitting them against each other head-to-head is a category error. CVSS asks "how bad could this be if exploited?" EPSS asks "how likely is exploitation in the near term?"
Used together, they form a two-axis prioritization model:
- High CVSS + High EPSS — severe and likely to be exploited. Top of the queue.
- High CVSS + Low EPSS — theoretically severe but currently quiet. Worth tracking, not an emergency.
- Low CVSS + High EPSS — modest technical severity but real-world attackers are actively going after it. Frequently underprioritized by CVSS-only programs.
- Low CVSS + Low EPSS — safe to defer.
EPSS data updates daily as FIRST retrains its model on new exploitation signals, which means a vulnerability's EPSS score can shift meaningfully within a week of disclosure — something a static CVSS Base score will never do. Any vulnerability management workflow that only ingests CVSS is, by definition, working from a stale risk picture the moment new exploitation activity emerges.
Where SSVC Fits: Decision Trees Over Single Scores
If CVSS and EPSS are inputs, SSVC is the output layer. Rather than collapsing risk into a single number, SSVC forces an explicit decision based on the context that actually matters to a given organization: Is the vulnerability exploited in the wild? Is the affected component reachable? Would exploitation cause serious mission impact or safety consequences for this specific deployment?
This is the model CISA itself uses for its own KEV (Known Exploited Vulnerabilities) prioritization guidance, and it's increasingly the direction vulnerability management is heading in general — away from "what's the score" and toward "what's the action." The practical implication for supply chain security tooling is that a scanner's job isn't complete when it reports a CVSS or EPSS number; it's complete when it tells an engineer whether to act now, track, or ignore, and why.
How Do Safeguard and Socket.dev Approach Vulnerability Scoring Differently?
Both companies operate in software supply chain security, but they've built around different center-of-gravity problems, and it's worth being concrete about the difference rather than making sweeping claims.
Scoring inputs. Safeguard's vulnerability workflow is built to ingest CVE identifiers, CVSS Base/Temporal scores, and EPSS probability data as first-class signals side by side, so severity and likelihood are visible together rather than requiring an analyst to cross-reference two separate feeds manually. Socket.dev's public-facing product materials describe a differently weighted approach: its "Socket Score" is oriented heavily around package-level supply chain risk signals — install scripts, obfuscated code, unusual maintainer behavior, and known-malware detection — which is a genuinely useful and distinct problem from CVE/CVSS/EPSS-based known-vulnerability triage. These are complementary risk surfaces, not the same one, and teams evaluating either tool should be clear on which problem they're buying a solution for.
Reachability-aware triage. Safeguard's scanning pipeline is designed to determine whether a vulnerable function in a dependency is actually reachable from application code before it factors into a team's action queue, which is what allows CVSS-severity and EPSS-likelihood signals to be filtered down to the findings that matter for a specific codebase rather than every match against a manifest. We'd encourage any team comparing tools on this dimension to ask vendors directly, including Socket.dev, exactly how deep their reachability analysis goes — call-graph level, import level, or manifest level — since this materially changes how much noise reduction a tool actually delivers versus how much it merely names as a marketing feature.
Where we're confident, and where we're not. We can speak precisely to how Safeguard handles CVE, CVSS, and EPSS ingestion because we build it. We're intentionally not asserting specific claims about Socket.dev's internal exploitation-prediction methodology, pricing, or incident history here, because those details aren't independently verifiable from the outside and don't belong in a fair comparison. If you're evaluating both platforms, the right move is to ask each vendor to walk through their scoring pipeline live, with a real dependency tree from your own codebase.
How Safeguard Helps
Safeguard's approach to vulnerability management is built around the layered model described above, not a single collapsed score:
- Unified CVE/CVSS/EPSS visibility — every finding surfaces its CVE identifier, CVSS Base score, and current EPSS probability together, so severity and real-world exploitation likelihood are never evaluated in isolation.
- Reachability analysis — findings are checked against actual code paths so teams see which vulnerable functions are truly callable from their application, not just present in a lockfile.
- SSVC-style action guidance — rather than stopping at a number, Safeguard's prioritization output is designed to answer the operational question every engineering team actually has: act now, schedule for the next sprint, or track and move on.
- Continuous rescoring — because EPSS scores shift daily as exploitation data changes, Safeguard's findings are designed to reflect updated likelihood rather than freezing risk at the moment of initial scan.
- SDLC-native integration — vulnerability findings flow into the same pipelines and pull requests where dependencies are introduced, so prioritization happens before code ships rather than as a separate post-hoc audit.
If your team is still triaging purely on CVSS severity, the fastest improvement you can make this quarter is layering in EPSS likelihood and reachability context before deciding what goes to the top of the queue. That single change — separating "how bad" from "how likely" from "does it even run here" — is usually what turns an unmanageable vulnerability backlog into a workable one.