What Is CVSS?

CVSS — the Common Vulnerability Scoring System — is an open industry standard for rating how severe a software vulnerability is, expressed as a single number from 0.0 to 10.0. It's what puts the number next to a CVE ("CVE-2026-XXXXX, CVSS 9.8 Critical") in a vulnerability scanner report or an advisory.

Quick definition: CVSS is a 0-10 severity score for a vulnerability, calculated from metrics covering how easy it is to exploit (the Base score's exploitability metrics) and what happens if it's exploited (the impact metrics).

How the score is built

The Base score — the number you see most often — combines two groups of metrics:

  • Exploitability metrics: Attack Vector (network, adjacent, local, physical), Attack Complexity, Privileges Required, and User Interaction — roughly, "how easy is this to actually pull off?"
  • Impact metrics: Confidentiality, Integrity, and Availability — each rated None, Low, or High — roughly, "how bad is it if someone succeeds?"

CVSS also defines optional Temporal metrics (does a working exploit exist? is there an official fix?) and Environmental metrics that let an organisation adjust the score for their own deployment — but in practice, the vast majority of CVSS scores you'll encounter in the wild are the unmodified Base score, calculated generically, without any environmental context.

Severity bands

ScoreRating
0.0None
0.1 – 3.9Low
4.0 – 6.9Medium
7.0 – 8.9High
9.0 – 10.0Critical

What CVSS is good for — and its key limitation

CVSS is genuinely useful as a common language: it lets a vendor, a scanner, and a customer all refer to the same severity for the same vulnerability without arguing about what "bad" means. It's also required or heavily referenced by most compliance frameworks (PCI-DSS, SOC 2, ISO 27001) for patch-prioritisation evidence.

Its limitation is baked into how it's calculated: the unmodified Base score is deliberately generic — it describes how bad a vulnerability is in the abstract, not how much risk it poses to your specific system. A 9.8-Critical remote code execution bug in a library your app imports but never actually calls poses close to zero real risk to you; a 5.4-Medium information-disclosure bug in your authentication flow, on a system holding sensitive threat models, might matter far more than the number suggests.

This gap between "generic severity" and "risk in your architecture" is exactly what a threat model — especially an attack tree scored by likelihood × impact for your specific system — is built to close. For the full argument (and a worked comparison), see The CVSS Trap: Why Vulnerability Severity Scores Break Down In Your Environment.

Score risk in your architecture, not in the abstract

ThreatTree's risk register scores each threat by likelihood × impact in the context of your own attack trees and DFDs — a complement to CVSS, not a replacement for the environmental judgment a generic score can't make for you.

Get started free

Not ready to sign up? Get new threat-modeling guides by email instead.