The exact CVSS v3.1 specification formula (FIRST.org), with a live breakdown of why the score is what it is, plus a second section that turns the score into what it actually means for your organization in dollars.
A CVSS score tells you how bad a vulnerability is technically - it says nothing about what it's actually worth in dollars to your organization, how many systems carry it, or how likely it is to get exploited. The Exposure Factor below is pre-filled from the severity above as a starting point, not a precise formula - adjust it for what this specific asset actually holds.
Severity is not likelihood, on purpose - this tool won't invent a formula that turns one into the other. A Critical score behind an air-gapped network can have near-zero real-world likelihood; a Low score on an internet-facing, unpatched, actively-scanned system can have very high likelihood. Ground the number above in what you actually know: is it on CISA's KEV list, is it internet-facing, how many instances are exposed, how fast can you patch.
CVSS gives you two sub-scores before it gives you the final number: Exploitability (how easy is this to actually pull off) and Impact (how bad is it once it succeeds). Two vulnerabilities can land on the same base score for completely different reasons - one because it's trivial to exploit but only leaks a little data, another because it's hard to reach but grants full system compromise. The breakdown above is there so you're prioritizing on the real shape of the risk, not just a single digit.
A patch-priority number worth knowing: CVSS severity alone doesn't tell you whether a vulnerability is being actively exploited in the wild. For that, cross-reference CISA's Known Exploited Vulnerabilities (KEV) catalog - a High-severity CVSS score with no known exploitation is a different priority than a Medium-severity one that's already on the KEV list with a mandated remediation deadline.
The "What does this mean for your organization" section deliberately doesn't invent a formula that converts CVSS severity into a likelihood of exploitation - those are two different questions. Severity tells you how bad it would be; the Annualized Rate of Occurrence you enter should come from what you actually know about this specific exposure (internet-facing or not, actively exploited or not, how fast you can patch), not from the score itself. The Exposure Factor field is pre-filled from severity purely as a starting point to edit, not a claim that it's precise.
Vulnerability count matters as much as severity: the same CVE sitting on 1 forgotten test server and on 500 production instances is not the same risk, which is why asset value and asset count are separate fields rather than one lump sum. The optional users/records field is there for data-exposure scenarios specifically (a breached database, not a defaced web server) - it asks for your own cost-per-record estimate rather than an industry-average figure, since that number varies enormously by regulation, jurisdiction, and what data was actually exposed.
Related terms: CVSS • CVE • Zero-Day • ALE
Want to actually practice vulnerability management and detection engineering, not just score one CVE?
Practice Free on Zamlom