
CVSS v4.0 scores vulnerability severity on a scale from 0 to 10 using the Base, Threat, Environmental and Supplemental metric groups, and the resulting number maps to one of five qualitative bands from None to Critical. Base metric values are combined with default values that assume the highest severity for Threat and Environmental metrics to produce a score ranging from 0 to 10; analysts can then refine that result with real threat intelligence and environment-specific factors. If you are preparing for CompTIA Security+ or CySA+, this is the mechanism exam questions probe: they hand you a scenario or a vector fragment and ask what the severity means and what you should do about it.
Method note: every scoring fact in this guide comes from two primary documents read during preparation — the CVSS v4.0 specification document (document version 1.2), owned and managed by FIRST.Org, and the NVD vulnerability metrics page from NIST, last updated June 27, 2024. Nothing below is written from memory or from third-party summaries, and the revision status of each source appears in the Sources section.
What CVSS v4.0 Measures
The Common Vulnerability Scoring System is an open framework for communicating the characteristics and severity of software vulnerabilities, and its outputs are numerical scores indicating severity relative to other vulnerabilities, not in absolute terms. That distinction is the most exam-relevant nuance in the whole topic: the NVD is blunt about this limitation and states that CVSS is not a measure of risk. A score says how severe a flaw is in a worst-reasonable-case sense; it says nothing about whether that flaw matters in your environment, what data sits behind the affected system, or what a regulator requires you to fix first. The specification expects consumers to use CVSS as one input to a vulnerability management process that also considers factors outside CVSS, such as regulatory requirements, the number of customers impacted, monetary losses or reputational damage.
The Four Metric Groups
CVSS v4.0 is built from four metric groups — Base, Threat, Environmental and Supplemental — and knowing who assigns each group is half of what exam scenarios test:
| Metric group | What it captures | Typical provider | Changes the score? |
|---|---|---|---|
| Base | Intrinsic qualities constant over time and across environments: exploitability and impact | Vendors and bulletin analysts | Yes — always assessed |
| Threat | Characteristics that change over time, such as proof-of-concept code or active exploitation | End consumers | Yes — optional refinement |
| Environmental | Characteristics unique to a consumer environment, such as mitigations and system criticality | End consumers | Yes — optional refinement |
| Supplemental | Extrinsic context such as safety impact and automatability | Providers; response set by the consumer | No — context only |
In practice, the NVD provides assessments of Base metrics only and does not currently assess Threat, Environmental or Supplemental metrics, although it supplies a CVSS calculator for each version so users can assess non-Base metrics themselves. The NVD supports the v2.0, v3.x and v4.0 standards and no longer issues CVSS v2.0 assessments for newly published CVE records. Because providers like the NVD typically publish only Base scores, the specification requires nomenclature that makes the metric mix explicit: a score labeled CVSS-B uses Base metrics only, CVSS-BT adds Threat metrics, CVSS-BE adds Environmental metrics, and CVSS-BTE uses all three scoring groups. When an exam question shows you a published score, assume it is a Base score unless the label says otherwise.
How Severity Bands Work
The qualitative bands that turn a number into a label are fixed by the specification: Low maps to 0.1-3.9, Medium to 4.0-6.9, High to 7.0-8.9 and Critical to 9.0-10.0, with 0.0 meaning no severity is scored. Two practical consequences follow for analysts. First, a Base score is a worst-reasonable-case estimate, so a High band on paper can drop once Environmental metrics show the affected system is isolated or already mitigated. Second, incomplete data pushes severity up, not down: when a vendor announces a vulnerability but declines to provide details, NVD enrichment assigns metric values using a worst-case approach and assesses such a vulnerability as 10.0, the highest rating. Treat an unexplained 10.0 as a signal to investigate the advisory, not as settled fact.
Reading a Vector String
Every CVSS assessment also produces a vector string: a compressed textual representation of the values used to derive the score. FIRST requires as a condition of use that anyone publishing CVSS data provides both the score and the vector string, so that others can understand how the score was derived. For exam work, train the reverse direction: given a vector, name the band and the likely remediation priority; given a scenario change such as a proof-of-concept exploit appearing or a mitigation being deployed, say which metric group changes and in which direction. A vulnerability with no public exploit can have its Threat-adjusted score lowered, while confirmed active exploitation moves the same record upward.
How Exams Test Scoring
Use this five-step procedure (our own study method, labeled as such) to lock in the scoring facts before exam day:
- Memorize the band boundaries cold: 0.1-3.9 Low, 4.0-6.9 Medium, 7.0-8.9 High, 9.0-10.0 Critical. These boundaries are straightforward points on exam day.
- Anchor each metric group to its owner: vendors assign Base values, consumers amend Threat and Environmental values, and Supplemental metrics never move the final score.
- Convert bands into actions: decide in advance what a Critical Base score should trigger in a patching timeline you would recommend, versus a Medium on an isolated internal system.
- Drill with real records: pick published CVE records on the NVD, read the vector string, predict the band, then check the answer.
- Test under time pressure: scoring questions should take seconds, so practice pacing with timed multiple-choice sets until reading a vector is automatic.
When you move beyond the core exams, the same scoring literacy transfers directly to specialized certifications: a structured domain-by-domain approach like our GCP Professional Cloud Security Engineer prep domain plan shows how to split a broader syllabus into study blocks, and if your next step is a proctored exam with hands-on delivery, read who conducts the CEH exam and how delivery works before you book a slot.