Open almost any penetration test report and each finding will carry a number between 0.0 and 10.0, a severity label and a cryptic string of letters. That is the Common Vulnerability Scoring System. Version 4.0, published by FIRST in 2023, changed how the score is built and how it should be quoted. If you decide fix priorities or report risk upward, it pays to know what the number does and does not tell you.
What CVSS is for
CVSS gives security teams a common language for how severe a vulnerability is. A tester in one organisation and an engineer in another can read the same vector and picture the same conditions: how the flaw is reached, what an attacker needs, and what it affects. That shared language makes reports comparable across providers and over time.
What CVSS does not do is know your business. It cannot tell that one server holds customer payment data and another hosts a test wiki. That context has to be added, either through the Environmental metrics or through your own prioritisation process.
The four metric groups
| Group | What it captures | Who usually sets it | Changes the score? |
|---|---|---|---|
| Base | Intrinsic qualities of the flaw: how it is reached and what it impacts | Tester or vendor | Yes |
| Threat | Whether exploitation is being seen or exploit code is available | Tester or consumer, updated over time | Yes |
| Environmental | How important the affected asset is to you and any controls in place | The organisation that owns the system | Yes |
| Supplemental | Extra context such as safety impact, automatability and recovery | Vendor or consumer | No; informational only |
Base metrics
The Base group splits into exploitability and impact. Exploitability covers the attack vector (network, adjacent, local or physical), attack complexity, the new attack requirements metric for conditions outside the attacker's control, privileges required and user interaction, which now distinguishes passive from active involvement. Impact is measured twice: on the vulnerable system itself and on subsequent systems that could be affected downstream. This replaces the old and often confusing Scope metric from version 3.1.
Threat metrics
The Threat group has a single metric, exploit maturity. It records whether attacks have been reported, whether a proof of concept exists, or neither. Adding threat data usually lowers the score of flaws nobody is exploiting and leaves actively attacked ones high, which is closer to how defenders want to prioritise.
Environmental metrics
Here the system owner states how much confidentiality, integrity and availability matter for the affected asset, and can modify any Base metric to reflect local conditions. A flaw reachable from the network in theory but sitting behind strict access controls in your deployment can be adjusted accordingly.
Supplemental metrics
These describe extra properties: whether exploitation could affect human safety, whether it can be automated across many targets, how a system recovers, the density of valuable resources, the effort needed to respond and any urgency set by the provider. They do not alter the numeric score, but they are useful for triage.
Reading the nomenclature
Version 4.0 asks everyone to say which groups were used. The label next to a score tells you how much context it contains.
- CVSS-B: Base metrics only. Most common in vendor advisories and many pentest reports.
- CVSS-BT: Base plus Threat.
- CVSS-BE: Base plus Environmental.
- CVSS-BTE: Base, Threat and Environmental together, the fullest picture.
If a report shows only a number without the label, ask. Comparing a CVSS-B score with a CVSS-BTE score is comparing different things.
Reading a vector string
The vector records every metric value used. An illustrative Base vector looks like this: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N. Read left to right, it describes a flaw reached over the network, with low complexity, no special preconditions, requiring a low-privilege account and no user interaction, with high confidentiality and low integrity impact on the vulnerable system and no effect on other systems. Keep the vector with the score in your tracking system. It lets anyone check the rating later and recalculate it if your environment changes.
Severity bands
| Rating | Score range | Typical handling |
|---|---|---|
| None | 0.0 | Informational; no action needed |
| Low | 0.1–3.9 | Fix in normal development cycles |
| Medium | 4.0–6.9 | Plan into near-term work |
| High | 7.0–8.9 | Prioritise; short fix window |
| Critical | 9.0–10.0 | Act immediately; consider interim mitigations |
The handling column is illustrative. Set your own target fix times in policy and apply them consistently.
What changed from version 3.1
- The Scope metric is gone, replaced by separate impact ratings for the vulnerable and subsequent systems.
- Attack Requirements is new, separating environmental preconditions from attack complexity.
- User Interaction gained more detail: none, passive or active.
- Temporal metrics became Threat metrics, simplified to exploit maturity.
- Supplemental metrics were added for context that should not move the score.
- Scoring now groups similar vectors and looks up their severity rather than relying on a single formula.
Using scores to drive remediation
A score is a starting point, not a to-do list. Good prioritisation blends CVSS with three other inputs:
- Asset importance. A Medium finding on a system holding customer data may outrank a High on an isolated test server.
- Exposure. Internet-facing issues usually come before those that need internal access.
- Chaining. Testers often combine several modest findings into a serious attack path. Read the narrative, not just the table.
Ask your provider to explain any finding where the score and their judgement diverge. A clear report will say why a technically Low issue still deserves attention. For turning ratings into fixed findings, see our remediation and retesting guide, and for questions to put to providers about reporting, see our RFP question list.
Frequently asked questions
Why does the same vulnerability score differently in two reports?
One report may show a Base score only (CVSS-B) while another includes threat or environmental context (CVSS-BT or CVSS-BTE). Always check which nomenclature is quoted next to the number.
Should we fix findings strictly in CVSS order?
No. Use the score as one input alongside asset value, exposure, exploit activity and the tester's narrative. A chain of Medium findings can matter more than one isolated High.
Is CVSS v3.1 still acceptable?
Many tools and databases still publish v3.1 scores. Ask your provider which version they use and keep it consistent across reports so trends remain comparable.
Want findings rated consistently and explained in business terms? Request a quote for a VAPT or web application pentest, or try the cost calculator.