What Is a CVSS Score? The Complete Guide to Reading Severity Ratings
Read the score, decode the vector, and keep technical severity separate from the risk in your environment.


The problem is not CVSS. It is using CVSS as if one number knows your network.
CVSS is a standard language for describing vulnerability severity. It tells you how an attack works, what an attacker needs, and what the technical impact can be. It does not know whether the affected product is running in your environment, whether the service is reachable, or whether the asset processes payroll.
Read the vector, keep the version, and treat the score as an input. If your process turns every 9.0 into the same ticket, the process has thrown away most of the useful information CVSS provides.
How to read a CVSS v4 vector
The number is a label. The vector records the assumptions behind it.
What is CVSS?
The Common Vulnerability Scoring System is an open framework maintained by FIRST. It communicates the characteristics and severity of software vulnerabilities through defined metrics, a vector string, and a score from 0.0 to 10.0.
NVD's vulnerability metrics guide states the boundary clearly: CVSS supplies a qualitative measure of severity and is not a measure of risk. NVD publishes Base assessments and supports versions 2.0, 3.x, and 4.0, but it does not supply the Threat, Environmental, or Supplemental assessments that belong to the consumer.
That is not a flaw. A public database cannot know your firewall policy, service owner, data sensitivity, or compensating controls. CVSS gives organizations a common starting point. Local analysis has to finish the job.
What do CVSS score ranges mean?
CVSS version 4 uses five qualitative bands:
| Rating | Score | What it says |
|---|---|---|
| None | 0.0 | No scored confidentiality, integrity, or availability impact |
| Low | 0.1 to 3.9 | Limited technical severity |
| Medium | 4.0 to 6.9 | Meaningful impact with constraints |
| High | 7.0 to 8.9 | Serious technical impact |
| Critical | 9.0 to 10.0 | The most severe combinations of access and impact |
These bands are labels, not service level agreements. A Medium issue on an exposed identity system can deserve faster work than a Critical issue in disabled software. The score describes the vulnerability under its assessed conditions. Priority describes what your organization should do.
Which CVSS v4 metric groups matter?
FIRST's official version 4 User Guide defines four metric groups. Each group has a different owner and useful life.
Base describes intrinsic severity
Base metrics cover how the attack reaches the vulnerable system, how difficult exploitation is, what privileges and user action are required, and what happens to confidentiality, integrity, and availability. They represent a reasonable worst case that remains stable across organizations.
Version 4 splits impact between the Vulnerable System and Subsequent Systems. That change replaced the older Scope concept. It lets an assessor distinguish damage to the component with the flaw from damage that crosses into another security authority.
Threat changes with attacker evidence
Threat contains Exploit Maturity. The value can reflect observed attacks, a public proof of concept, unreported exploit evidence, or an undefined state. In version 4, this group replaces the older Temporal group. Threat evidence should be refreshed because public exploits and active campaigns appear after initial disclosure.
Environmental belongs to you
Environmental metrics modify the assessment for the deployed system. They include local security requirements and modified versions of Base metrics. A web application firewall that materially increases attack complexity may change the local assessment. So can an architecture where availability matters far more than confidentiality.
Document the proof. "Behind a firewall" is not enough. Name the rule, tested path, owner, and expiration. Otherwise the environmental score becomes an unsupported opinion.
Supplemental helps break ties
Supplemental metrics add context such as Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, and Provider Urgency. They do not change the final score. They help an operator understand why two findings with the same number may demand different actions.
How do you read a CVSS v4 vector string?
Start with the version, then read left to right. This example comes from FIRST's current examples:
AV:Nmeans the attack vector is Network.AC:Lmeans attack complexity is Low.AT:Nmeans no attack prerequisite condition is present.PR:Lmeans the attacker needs Low privileges.UI:Nmeans no user interaction is required.VA:Hmeans impact to vulnerable system availability is High, while the other listed impacts are None.
FIRST added this Windows Kerberos example on July 2, 2026, a recent change many older CVSS explainers do not contain. Its official CVSS v4 examples give the vector a Base score of 7.1. The description is a denial of service reachable over a network by an authorized attacker. The vector tells that story more precisely than "High."
Store the vector with the score. FIRST requires published CVSS data to include both so another analyst can see how the number was derived. If an integration retains only 7.1, it discards the explanation needed for review.
What changed from CVSS v3.1 to v4.0?
Version 4 did more than rename fields. Attack Requirements became a new Base metric. User Interaction split into None, Passive, and Active. Scope disappeared in favor of explicit impacts to the vulnerable and subsequent systems. Temporal became Threat. Supplemental context gained a formal home.
The new nomenclature also shows which groups were explicitly used. CVSS-B means Base.CVSS-BT adds Threat. CVSS-BE adds Environmental. CVSS-BTE contains all three scoring groups. A bare number hides that maturity.
Do not convert old vectors by replacing the version label. Metric definitions and the scoring method changed. Preserve the original assessment, then create a version 4 assessment from source evidence when the work justifies it.
How should a security team use CVSS?
Begin with Base metrics to understand the technical attack. Read the vector before the description written by a ticketing integration. Check the source and version.
Threat evidence comes next. Is exploitation observed? Is a proof of concept public? Has exploit maturity changed since disclosure? Assess the local environment too: product presence, feature state, exposure, identity path, controls, asset importance, and blast radius.
Send the result through the vulnerability prioritization framework. The action can be patch, configuration change, containment, retirement, or a time bound risk acceptance. The CVSS score should never be the only sentence in the reason.
Capacity makes this discipline necessary. Four analysts reviewing 50 "High or Critical" findings each week can examine 200. If the scanner produces 2,000, severity sorting leaves 1,800 untouched with no reasoning. Applying threat and local gates first lets analysts spend their 200 reviews on findings where judgment changes an action.
How can one CVSS score lead to different actions?
Take the 7.1 Windows Kerberos denial of service example from FIRST. The public Base vector is the same wherever the affected software exists. The action changes when the deployment changes.
| Asset | Local evidence | Business effect | Action |
|---|---|---|---|
| Primary domain controller | Affected build, reachable by domain users | Authentication outage across production | Expedited patch and failover test |
| Secondary controller | Affected build, access restricted | Reduced redundancy during failure | Patch in the next approved window |
| Retired lab image | Not running, deployment blocked | No current service impact | Remove image and verify inventory |
None of these actions disputes the Base assessment. They finish it. The first system has a material availability requirement and a broad authenticated attack population. The second has a narrower path and a fallback. The third is not an active vulnerable instance, but leaving the image available could recreate one.
This is why a scanner severity cannot be copied directly into a deadline. The vector describes the technical case. Asset state and service consequence turn it into work. Preserve both layers so an auditor can see that the organization did not change a standard score to make the dashboard look better.
Which CVSS source should you trust when scores disagree?
Start with the product vendor or maintainer because it knows the affected implementation. Compare that vector with the CVE record and NVD assessment. Differences are not automatically errors. A vendor may score a specific platform while NVD assesses a broader reasonable worst case.
Resolve disagreement by comparing vector metrics one at a time. Did one source assume network access while another assumed local access? Did one include subsequent system impact? Did they assess different product builds? Store the chosen source and written reason. Never average the numbers. An average hides both attack models and produces a score nobody actually assessed.
Set a source order in policy before the next urgent disclosure. The policy might prefer the maintainer for affected product facts, NVD for independent enrichment, and your own Environmental assessment for deployed controls and mission requirements. Permit exceptions when evidence supports them. Require the analyst to name the metric that changed and attach the source. This turns a score conflict from an argument into a reviewable technical decision.
Which CVSS mistakes create bad decisions?
The first mistake is calling CVSS a risk score. NVD and FIRST both reject that usage. Risk needs threat and local consequence.
Another is comparing scores across versions as if the metrics were identical. Keep the version beside every score. Avoid mixing a v3.1 queue and a v4.0 queue without a clear policy.
Teams also lose the vector, inherit the highest vendor score across every platform, or leave Environmental values untouched for years. Each shortcut makes the number easier to display and harder to defend.
The worst mistake is tying automatic patch deadlines to Base bands alone. FIRST updated its CVSS v4 FAQ on patch priority on June 24, 2026, then updated vector guidance again on July 17. The FAQ says Base scores are not risk and should not be used alone for patch priority. Use technical impact as one input to a broader decision.
Frequently asked questions
Is a CVSS score of 9 or 10 always urgent?
No. It is always technically severe under the assessed conditions. Urgency depends on presence, reachability, attacker activity, business consequence, controls, and fix options.
Who assigns CVSS scores?
Product vendors, CVE Numbering Authorities, NVD analysts, and other assessment providers may publish Base vectors. The organization using the software owns its Threat and Environmental enrichment.
Does EPSS replace CVSS?
No. CVSS describes severity. EPSS estimates the probability of observed exploitation in the next 30 days. Compare them in the CVSS versus EPSS guide.
Can two organizations assign different CVSS values to the same CVE?
Yes. Their Base assessments can differ if source facts or affected platforms differ. Their Environmental assessments should differ when deployment conditions and security requirements differ.
Executive takeaway
Keep CVSS, but use all of it. Store the version, score, vector, source, and assessment date. Read the attack path before setting a deadline. Then add exploit evidence and local system facts through the vulnerability exploitability review. This week, sample 25 urgent tickets and count how many retain the vector and a local reason. That number will tell you whether your queue is analysis or decoration.
See which of your findings actually matter
Artemes AI combines deep endpoint context with AI-driven analysis to show which findings are actually exploitable on your hosts—not just everything a scanner can list. We are onboarding early access teams now.

Chris Seymour
Chris writes about vulnerability prioritization, exploitability, AI-assisted remediation, and the engineering realities of turning scanner output into remediation decisions.

