CVSS Scoring
The Common Vulnerability Scoring System — how vulnerability severity is measured
What is CVSS?
CVSS stands for Common Vulnerability Scoring System. It is an open framework maintained by FIRST (Forum of Incident Response and Security Teams) for describing vulnerability severity in a consistent way across vendors, scanners, and databases. Official resources are available at FIRST CVSS, and the current specification is CVSS v4.0 at CVSS v4.0 specification. CVSS produces a numerical score from 0.0 to 10.0 and maps it to qualitative bands: None, Low, Medium, High, and Critical.
The primary value of CVSS is standardisation. Different researchers can describe technical exploit conditions and likely impact using a shared metric vocabulary, then generate comparable scores. That improves machine processing and triage workflows, especially when organisations consume vulnerability data at scale. CVSS is not a replacement for business risk assessment; it is a technical severity model. It answers, “How severe is this vulnerability in general conditions?” not “How damaging would this be in our exact environment today?” Understanding that boundary prevents common misuse in patch policies.
CVSS v3.1 (Still Widely Used)
CVSS v3.1 remains widely used in NVD entries, vendor advisories, and scanner outputs even after v4.0 release. The v3.1 specification is at CVSS v3.1 specification. It defines three metric groups. Base metrics describe intrinsic characteristics of a vulnerability that do not change across environments. Temporal metrics capture factors that evolve over time, such as exploit maturity and remediation level. Environmental metrics adjust scoring to local context, including asset importance and security control posture.
In practice, most published scores are Base only because Temporal and Environmental scoring requires ongoing analyst input and organisation-specific data. That creates a useful but limited severity indicator. A Base score helps compare vulnerabilities technically, but it does not reflect your exact threat model or control maturity. Teams that rely solely on Base scores often over-prioritise noisy high scores and under-prioritise lower-scored vulnerabilities with stronger exploitation indicators. Knowing v3.1 structure helps you interpret what is present and, equally important, what is missing in typical feed data.
Base Score Metrics
Base scoring in v3.1 uses exploitability and impact metrics. Attack Vector (AV) indicates how remotely an attacker can reach the vulnerable component: Network, Adjacent, Local, or Physical. Attack Complexity (AC) captures whether exploitation needs unusual preconditions. Privileges Required (PR) indicates required access level before exploitation. User Interaction (UI) indicates whether a victim must perform an action, such as opening a malicious file. Scope (S) reflects whether exploitation crosses a security boundary into another component. Impact metrics then assess confidentiality, integrity, and availability consequences.
Concrete examples help. A pre-auth remote code execution bug in a public web service might be AV:N, AC:L, PR:N, UI:N with high C/I/A impact, typically scoring near Critical. A local privilege escalation requiring prior shell access could be AV:L and PR:L, often lower despite serious post-compromise implications. A phishing-dependent macro exploit might include UI:R because user action is mandatory. Scope changes, such as escaping from one sandboxed service to host control, can significantly raise score. These metrics are structured shorthand for exploit conditions, not arbitrary labels.
CVSS v4.0 (Current)
CVSS v4.0 was released in November 2023 and is now the current standard. Overview material is at CVSS v4.0. It introduces structural updates intended to improve score precision and usability. Notable changes include replacing Attack Complexity with Attack Requirements to better model conditions outside attacker control, removing Scope as a standalone metric, and refining impact representation. v4.0 also adds Supplemental metrics that provide additional context without changing the core base score.
Supplemental metrics include concepts like Automatable, Recovery, and Provider Urgency, which help organisations communicate operational implications beyond raw severity. The intent is to address long-standing v3.1 criticism around oversimplification and limited differentiation among high-severity findings. Adoption is gradual because ecosystems need database, scanner, and vendor support updates. For now, analysts often work in mixed mode: consuming v3.1 where only legacy scores exist while interpreting v4.0 where available. Understanding both versions is therefore operationally necessary.
Reading a CVSS Vector
CVSS vectors encode metric choices in compact form. Example: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. This vector commonly maps to a 9.8 Critical score. Decode it step by step: AV:N means exploitable over network; AC:L means low complexity; PR:N means no prior privileges required; UI:N means no user interaction needed; S:U means scope unchanged; and C:H/I:H/A:H means high impact on confidentiality, integrity, and availability.
Vector literacy improves triage quality. Two vulnerabilities might both be “High,” but one may require local authenticated access while the other is pre-auth remote on a public endpoint. Those conditions imply different urgency in production. Analysts should read vectors alongside asset exposure and exploit intelligence rather than only consuming the final score. Many tooling platforms display score prominently but hide vector detail in secondary views. Training teams to interpret vectors directly helps avoid false equivalence between vulnerabilities that have very different exploit paths.
Limitations of CVSS
CVSS Base score does not model real-world exploitation probability. A technically severe vulnerability may never be weaponised, while moderate-severity issues can become active attack favorites. That gap is one reason EPSS exists; see FIRST EPSS. CVSS Environmental scoring can represent local context, but many organisations do not compute it due to data and workflow overhead. As a result, patch queues often reflect generic severity rather than organisation-specific risk exposure.
Another operational issue is patch fatigue. Large environments can receive hundreds of High and Critical findings weekly. If teams treat all high scores as equal emergencies, remediation capacity fragments and SLA performance degrades. CVSS should be combined with exploitability data, asset criticality, and business function impact. Used correctly, CVSS standardises technical severity communication. Used in isolation, it can produce noisy prioritisation and defensive inefficiency, especially in environments with limited patch windows and strict change controls.
CVSS in Practice
Organisations commonly map CVSS severity bands to remediation SLAs. A typical model might set Critical findings to 48 hours, High to 7 days, and Medium to 30 days, with variation by asset class and exposure. CVSS data often enters workflows through NVD enrichment, vendor advisories, and scanner integrations. Compliance frameworks also reference severity-based remediation timelines, which makes CVSS a practical governance anchor for reporting and audit evidence.
Effective teams treat SLA thresholds as a starting control, not a rigid rule. They override urgency upward for KEV-listed vulnerabilities, high EPSS probabilities, and externally exposed critical systems. They may de-escalate findings where compensating controls are strong and validated. This blended model improves both security outcomes and change stability. CVSS remains central because it standardises severity language, but modern vulnerability management pairs it with exploitation intelligence and environment context to produce defensible, high-value prioritisation.
Continue Learning
- EPSS & KEV — Add exploitation likelihood and confirmed exploitation signals to CVSS-based triage.
- Vulnerability Management — Place CVSS in a full discovery-to-remediation operating cycle.
- Risk Assessment — Convert technical severity into business-impact treatment decisions.