When a scanner flags a vulnerability as "CVSS 7.5," most teams treat that number as gospel — a fixed, universal measure of danger. Snyk's Risk Score breaks that assumption. Instead of reusing the 0–10 CVSS scale, Snyk recalculates severity on a 0–1000 range that starts from the CVSS impact subscore and then layers in exploit maturity, real-world exploitation signals, and reachability data. Two findings with an identical CVSS Base Score of 7.5 can land at 210 and 810 on Snyk's scale, because the underlying impact math and the surrounding threat context diverge. Understanding how that expansion happens — from the three-part CVSS impact formula (confidentiality, integrity, availability) through to Snyk's additional risk factors — is essential for any team trying to explain why its "critical" backlog looks different in Snyk than it does in a raw NVD feed. This post walks through the publicly documented mechanics, step by step.
What is the Snyk Risk Score, and why not just use CVSS?
The Snyk Risk Score is a 0–1000 numeric rating Snyk assigns to vulnerabilities in place of, or alongside, the traditional 0–10 CVSS severity score. Snyk introduced it because CVSS was designed in 2005 (and last majorly revised as CVSS v3.1 in 2019 by FIRST.org) to describe the technical severity of a flaw in isolation — it says nothing about whether a public exploit exists, whether the vulnerable code path is actually reachable in your application, or whether attackers are actively targeting it this month. CVSS's 0–10 range also compresses a lot of real-world variance into a narrow band: the vast majority of published CVEs cluster between 7.0 and 9.8, making it hard to rank-order a backlog of hundreds of findings. By rescaling to 0–1000 and blending in exploit and context signals, Snyk creates enough numeric headroom to separate "technically severe but dormant" from "technically severe and actively weaponized."
How is the CVSS impact subscore actually calculated?
The CVSS impact subscore is a formula, not a guess, and it is the anchor Snyk's score builds on. Under CVSS v3.1, each vulnerability gets three impact metrics — Confidentiality (C), Integrity (I), and Availability (A) — each rated None (0), Low (0.22), or High (0.56). FIRST.org's published specification combines them into an Impact Sub-Score (ISS) using: ISS = 1 − [(1 − C) × (1 − I) × (1 − A)]. If the vulnerability's Scope is "Unchanged," the final Impact score is 6.42 × ISS. If Scope is "Changed" (the exploit affects components beyond the vulnerable one), it uses the steeper formula 7.52 × (ISS − 0.029) − 3.25 × (ISS − 0.02)^15. For example, a flaw with High confidentiality, integrity, and availability impact (C=I=A=0.56) produces an ISS of 1 − (0.44 × 0.44 × 0.44) = 0.9148, which under an unchanged scope yields an Impact score of roughly 5.87 out of a maximum 6.05. This impact figure is then combined with CVSS's separate exploitability metrics (attack vector, complexity, privileges required, user interaction) to produce the familiar 0–10 Base Score — and it's this impact component specifically that Snyk uses as one of the foundational inputs to its own 0–1000 calculation.
What other signals get layered on top of the CVSS impact subscore?
Snyk's public documentation describes four categories of additional signal beyond the raw CVSS impact math: exploit maturity, social/community trends, exploit prediction data, and reachability. Exploit maturity is a categorical field Snyk maintains per vulnerability — labeled something like "Mature" (weaponized, reliable public exploit code exists), "Proof of Concept" (a PoC exists but isn't production-grade), "No Known Exploit," or "No Data" — and a vulnerability with a mature exploit is weighted up relative to one with none. Social trends capture whether a CVE is generating unusual discussion volume (security researchers, Twitter/X, forums), which historically correlates with a spike in exploitation attempts. Snyk also references exploit-prediction-style scoring similar in spirit to FIRST.org's EPSS (Exploit Prediction Scoring System), which estimates the probability a CVE will be exploited in the wild within the next 30 days based on historical exploitation patterns across tens of thousands of CVEs. Finally, for languages where Snyk Code or Snyk Open Source can perform reachability analysis, whether the vulnerable function is actually called by your application's code paths affects the score — an unreachable vulnerable function in a dependency you never invoke poses materially less real-world risk than one sitting directly in your request-handling path.
How does Snyk map all of that onto a 0–1000 number?
Snyk normalizes the combined inputs onto a 0–1000 scale and then buckets the result into four severity bands that mirror, but don't exactly match, legacy CVSS Low/Medium/High/Critical labels. Snyk's own scoring documentation groups the range roughly as: 0–199 (Low), 200–499 (Medium), 500–799 (High), and 800–1000 (Critical). The exact weighting formula that turns the CVSS impact subscore, exploit maturity, social trends, and reachability into a single number is not published in full mathematical detail — Snyk describes it as a proprietary aggregation rather than a simple weighted sum — but the directional logic is public: higher impact, more mature exploits, more community attention, and confirmed reachability all push the score up toward 1000, while low impact, no known exploit, and unreachable code push it down toward 0. This is a meaningful transparency gap worth noting for teams that need to justify prioritization decisions to auditors: you can see and verify the CVSS-derived inputs, but the exact combination function is a black box.
Why can two vulnerabilities with the same CVSS score land in different Risk Score bands?
Because CVSS Base Score only captures technical severity at disclosure time, while Snyk's score reacts to what's happened since. Take two hypothetical CVEs both published with a CVSS v3.1 Base Score of 7.5 (High) and identical High/None/None impact metrics. If CVE-A has had a Metasploit module published, is trending in security research forums, and sits in a code path your app actively calls, its Snyk Risk Score could land at 850+ (Critical band). If CVE-B has no known exploit, no public discussion, and lives in a dependency function your application never executes, it could sit at 220 (Medium band) — despite an identical starting CVSS score. This divergence is the entire point of the exercise: it lets security teams stop triaging a flat list of "High" and "Critical" CVEs in the order NVD published them, and instead work down a list ordered by which vulnerabilities are both technically severe and currently dangerous.
How Safeguard Helps
Safeguard's supply chain security platform is built around the same underlying insight that motivates scores like this one: a CVSS number alone is a poor proxy for real-world risk, and the inputs that actually predict exploitation — reachability, exploit maturity, and package provenance — need to be visible and auditable, not buried in a proprietary formula. Safeguard surfaces dependency vulnerabilities alongside reachability analysis and provenance data (where a package came from, whether it's been tampered with, and whether your build actually exercises the vulnerable code path) so teams can build their own defensible prioritization logic rather than relying solely on a vendor's black-box score. For organizations already using Snyk's Risk Score for day-to-day triage, Safeguard adds a complementary layer of SBOM-level visibility and build provenance verification, helping security and compliance teams answer the audit question that risk scores alone can't: not just "how severe is this CVE," but "how did this vulnerable package get into our software in the first place, and can we prove it." That combination — score-based prioritization plus provenance-based root-cause tracing — is what turns a vulnerability list into a defensible, SOC 2-ready remediation program.