A CVSS score is a number from 0.0 to 10.0 that rates how severe a software security flaw is, where higher means worse. CVSS stands for the Common Vulnerability Scoring System, an open, industry-wide standard. When you read that a vulnerability is "CVSS 9.8," someone has run the flaw's characteristics through a defined formula to produce that rating, along with a plain-language label from None to Critical. The point is to give the whole security world a shared way of answering one deceptively simple question: how bad is this?
Why It Matters
Every organization faces far more security flaws than it could ever fix at once. Tens of thousands of new vulnerabilities are cataloged every year, and any real application inherits hundreds through the outside code it relies on. Without a common measure of severity, every alert would look equally urgent, which is the same as no alert being urgent. CVSS gives teams a first, standardized way to sort the pile: deal with the 9s before the 3s.
That shared scale is also why CVSS shows up everywhere — in vulnerability databases, vendor bulletins, compliance rules, and internal policies. A company might set a rule like "fix every Critical flaw within a week." So even if you never calculate a score yourself, you will constantly encounter them, and being able to read one correctly is a genuinely useful skill. The catch, which we will come back to, is that the number describes a flaw in the abstract — not necessarily the risk it poses to your specific situation.
A Simple Analogy: A Weather Severity Scale
Think of a CVSS score like a storm severity rating. A category 5 hurricane is objectively more dangerous than a category 1, and the rating helps everyone speak the same language about what is coming. But the rating alone does not tell you your personal risk. A category 5 storm hundreds of miles out to sea may matter less to you than a modest category 1 heading straight for your town. Same with CVSS: a terrifying 9.8 in a component your app never actually runs may matter less than a mild-looking 6.0 sitting on your login page. The score measures the storm; it does not measure how close you are standing.
Key Things to Know
The score always comes with a severity label, and the bands are worth memorizing:
| Score range | Severity label |
|---|---|
| 0.0 | None |
| 0.1 to 3.9 | Low |
| 4.0 to 6.9 | Medium |
| 7.0 to 8.9 | High |
| 9.0 to 10.0 | Critical |
A handful of points will keep you from misreading scores:
- The number reflects fixed traits of the flaw — things like whether it can be exploited over the internet, whether an attacker needs an account first, and how much damage a successful attack does.
- It measures severity, not likelihood. A high score means "this would be bad if exploited," not "this will be exploited." A separate system called EPSS estimates the odds of actual exploitation.
- Versions differ. You will see scores from CVSS 3.1 and the newer 4.0. They are calculated a little differently, so avoid comparing a 3.1 score directly against a 4.0 score as if they were identical.
- The same flaw can score differently depending on who scored it, because some judgment is involved. When two sources disagree, that is normal, not a mistake.
The single most important takeaway: never patch by CVSS score alone. It is one strong input, but the smartest teams blend it with how likely the flaw is to be attacked and whether their own software even runs the vulnerable code.
How Safeguard Helps
A raw list of CVSS scores across hundreds of dependencies is overwhelming, and sorting purely by the highest number sends you chasing flaws that may pose no real risk to you. Safeguard's software composition analysis attaches the full CVSS rating to every finding, then layers on two things the score cannot tell you by itself: how likely the flaw is to be exploited, and whether your application actually runs the affected code. A theoretical 9.8 in an unused path drops down the list; a live, reachable 7.0 rises to the top.
Because working that out by hand across a big project is tedious, Griffin AI does it continuously and explains its reasoning in plain language. To learn the neighboring ideas — CVE identifiers, severity, exploit likelihood — the concepts library lays them out simply. To see prioritized scores on your own dependencies, create a free account, or build the fundamentals step by step in Safeguard Academy.
Frequently Asked Questions
Does a higher CVSS score always mean I should fix it first?
Not automatically. CVSS measures how severe a flaw is in general, not how much risk it poses to your particular system. A Critical-rated flaw in a component your application never actually uses can be lower priority than a Medium-rated one sitting on an internet-facing page that runs all day. The best approach blends the score with exploit likelihood and whether your code truly runs the vulnerable part.
What is the difference between a CVSS score and a CVE?
They work together but answer different questions. A CVE is the unique identifier for a specific vulnerability — like a serial number, for example CVE-2021-44228. A CVSS score is the severity rating attached to that vulnerability. So a single CVE will typically have a CVSS score describing how dangerous it is. One names the flaw; the other rates it.
Why do I sometimes see different scores for the same flaw?
Because scoring involves some analyst judgment, and different organizations may assess the same flaw slightly differently or use different CVSS versions. A software vendor might score a flaw within the narrow context of their product, while a national database scores it more generically. When scores disagree, it usually reflects a difference in perspective rather than one source being simply wrong.
Do I need to understand the formula to use CVSS?
No. For everyday use, knowing the 0 to 10 scale and its severity labels is enough to make sense of a score. The detailed formula matters mostly to the people producing scores. What matters for you is remembering that the number is a starting point for triage, not a final verdict on your risk.