TL;DR: CVSS helps IT teams compare vulnerability severity, but patching decisions should also account for active exploitation, internet exposure, asset criticality, business impact, and available fixes. Base metrics describe exploitability and impact, while Threat and Environmental metrics add current and organization-specific context. Calculators, vulnerability scanners, management platforms, and patching tools can then support a repeatable workflow: detect affected systems, prioritize findings, test and deploy fixes, rescan devices, and verify that the vulnerability has been remediated.
The Common Vulnerability Scoring System (CVSS) is an open framework for communicating the characteristics and severity of software, hardware, and firmware vulnerabilities. Originally commissioned by the National Infrastructure Advisory Council, CVSS is now owned and maintained by the Forum of Incident Response and Security Teams (FIRST). It produces a numerical severity score that organizations can use as one input when prioritizing remediation.
Note 1: There are several versions of CVSS floating around the internet. This article focuses primarily on v4.0 (the way of the future), but CVSS v3.1 is still widely used, including by PDQ. Version 4.0 adds Attack Requirements and Supplemental metrics, refines User Interaction, separates impacts to the vulnerable system from impacts to subsequent systems, and replaces v3.1’s Temporal metric group with a simplified Threat group. Check the vector prefix — CVSS:4.0 or CVSS:3.1 — to identify the version used for a particular score.
Just keep in mind that exact details vary depending on which CVSS version you’re looking at.
Note 2: CVSS uses a lot of abbreviations to identify its vast array of metrics. We’re including them here, but please don’t let the alphabet soup bog you down.
Base metrics
Base metrics focus on the intrinsic security vulnerability characteristics that are consistent regardless of the time, place, and environment. These values are typically assigned by an analyst or the vendor. The base metrics break down into two categories: exploitability and impact.
CVSS v4.0 base score severity levels
None | 0.0 |
Low | 0.1–3.9 |
Medium | 4–6.9 |
High | 7–8.9 |
Critical | 9–10 |
Exploitability metrics
Exploitability metrics relate to how easy it would be for a threat actor to exploit a software vulnerability assuming they have knowledge of the target.
Attack Vector (AV)
The Attack Vector metric indicates the context of possible exploitation. The severity is higher if a known vulnerability can be exploited remotely.
Attack Complexity (AC)
Attack Complexity reflects whether an attacker must evade or overcome security-enhancing conditions to exploit the vulnerability.
Attack Requirements (AT)
The Attack Requirements metric captures prerequisite deployment or execution conditions that must exist for the attack to succeed, such as a race condition or an on-path network position.
Privileges Required (PR)
Privileges Required addresses the privileges an attacker needs before exploiting the vulnerability.
User Interaction (UI)
As the name suggests, User Interaction focuses on whether a user must participate (and how actively) for an attacker to successfully compromise a vulnerable system.
Impact metrics
Impact metrics focus on the direct expected effects if threat actors successfully exploit a vulnerability. Each impact metric subcategory also breaks down into two sub-subcategories based on whether the impacted system is the vulnerable system itself or a subsequent system.
Confidentiality Impact (VC/SC)
The Confidentiality Impact metric assesses how a successfully exploited vulnerability may impact information confidentiality on the target system.
Integrity Impact (VI/SI)
This metric focuses on how an exploited vulnerability could affect the trustworthiness of information.
Availability Impact (VA/SA)
This Availability metric addresses whether or not the impacted system will remain available if an attacker successfully exploits a vulnerability.
Threat metrics
Threat metrics are assessed by CVSS consumers using current threat intelligence and cover characteristics that may change over time. Although organizations can use a Base score alone, adding Threat metrics can make the result more relevant to current exploit activity.
Exploit Maturity (E)
Formerly known as Exploit Code Maturity, Exploit Maturity looks at how likely it is that a vulnerability will be exploited in its current state based on exploit code availability and techniques, along with whether it is already being actively exploited.
Environmental metrics
Environmental metrics are organizationally assigned and refer to vulnerability characteristics relevant in a specific environment. It’s not essential to measure environmental metrics, but it can make results more specific and readily applicable.
Confidentiality, Integrity, and Availability Requirement (CR, IR, AR)
These customizable metrics essentially allow you to weigh the importance of confidentiality, integrity, and availability based on your business needs.
Modified base metrics
Modified base metrics allow you to adjust the base metrics (exploitability and impact metrics) to suit your environment. Note that you can also assign a Safety metric if human safety may be affected by availability or integrity issues in subsequent systems.
The modified CVSS base metric options break down as follows:
Modified Attack Vector (MAV)
Modified Attack Complexity (MAC)
Modified Attack Requirements (MAT)
Modified Privileges Required (MPR)
Modified User Interaction (MUI)
Modified Vulnerable System Confidentiality (MVC)
Modified Vulnerable System Integrity (MVI)
Modified Vulnerable System Availability (MVA)
Modified Subsequent System Confidentiality (MSC)
Modified Subsequent System Integrity (MSI)
Modified Subsequent System Availability (MSA)
Supplemental metrics
Supplemental metrics provide additional context about a vulnerability but do not change the calculated CVSS score. Organizations may incorporate this information into their own risk-analysis and prioritization processes.
Safety (S)
In addition to indicating safety concerns within a modified base metric, you can also use the Safety supplemental metric if a human could face harm as a result of an exploited vulnerability.
Automatable (AU)
This CVSS metric measures whether a threat actor could automate the exploitation of a vulnerability across targets.
Provider Urgency (U)
Provider Urgency is a supplemental metric that vendors can add to reflect how pressing they consider the vulnerability.
Recovery (R)
The Recovery metric measures how easy it is to recover services once a system has been compromised.
Value Density (V)
Value Density assesses how many resources an attacker may control after exploiting a single vulnerable component.
Vulnerability Response Effort (RE)
The Vulnerability Response Effort metric focuses on how challenging it would be for a consumer to respond to the potential impacts of a vulnerability.
How do you prioritize which vulnerabilities to patch first?
Use CVSS as a severity baseline, not a complete risk score. Start with the Base score, then raise or lower the priority using Threat and Environmental metrics, CISA KEV status, exploit probability, internet exposure, asset criticality, business impact, and patch availability.
Priority | Typical signals | Sample remediation target |
|---|---|---|
Emergency | CISA KEV or confirmed active exploitation affecting an internet-facing or business-critical asset | Mitigate within 24 hours and patch within 24 to 72 hours |
Critical | CVSS 9.0 to 10.0, especially with network access, low complexity, no required privileges, or high Environmental impact | 24 to 72 hours |
High | CVSS 7.0 to 8.9 without confirmed active exploitation | 7 days |
Medium | CVSS 4.0 to 6.9 with limited exposure or business impact | 30 days |
Low | CVSS 0.1 to 3.9 with low exposure and limited impact | Next maintenance window, often within 60 to 90 days |
Treat these as sample service-level targets, not requirements built into CVSS. Adjust them for compliance obligations, service criticality, testing requirements, available mitigations, and the operational risk of applying the patch.
What tools help prioritize vulnerabilities?
CVSS calculators help assess vulnerability severity, while vulnerability management and patching tools add context and support remediation. Together, these tools help IT teams turn CVSS scores into practical patching priorities.
Tool category | What it does | How it uses CVSS | Example |
|---|---|---|---|
CVSS calculators | Calculate or customize vulnerability severity | Applies Base, Threat, and Environmental metrics | |
Find CVEs across devices and software | Uses CVSS alongside exploitability and environmental context | ||
Rank findings by real-world risk | Combines CVSS with business impact, exposure, and exploitability | ||
Deploy fixes and confirm remediation | Turns prioritized findings into patching actions |
What does a vulnerability-to-patch workflow look like?
A vulnerability-to-patch workflow helps IT teams move from identifying a security issue to confirming that the risk has been resolved. The process typically includes detection, prioritization, deployment, and verification.
Detect the vulnerability: Scan endpoints and map each finding to its CVE, affected software, impacted devices, and available fixes.
Triage the finding: Assign a priority using CVSS, CISA KEV status, Exploit Maturity or EPSS, internet exposure, asset criticality, and business impact.
Test and deploy the fix: Test the patch with a pilot group before expanding the deployment. For emergency vulnerabilities, use a documented mitigation or accelerated rollout if full testing would cause the organization to miss its target.
Verify remediation: Rescan affected systems, confirm the vulnerable versions are gone, investigate failed deployments, and document exceptions. Maintain a rollback plan and a remote access option for devices that need recovery.
CVSS FAQs
What’s the difference between CVSS and CVE?
CVE assigns standardized identifiers and records to publicly disclosed vulnerabilities, while CVSS measures vulnerability severity. The National Vulnerability Database ingests CVE records and may enrich them with CVSS scores, weakness classifications, affected-product information, and other metadata. In simple terms, CVE tells you which vulnerability is being discussed; CVSS helps communicate how severe it is.
What are the different types of CVSS scores?
While the CVSS base score (CVSS-B) is most widely known, inputting additional information creates more customized options: CVSS base and threat (CVSS-BT); CVSS base and environmental (CVSS-BE); and CVSS base, threat, and environmental (CVSS-BTE).
How can I calculate a CVSS score?
The easiest way to calculate a CVSS score that’s custom to your unique environment is by using NVD’s CVSS calculator or FIRST’s CVSS calculator. NVD vulnerability pages may also display one or more CVSS scores from NVD analysts, CVE Numbering Authorities, or other sources when available. For a score tailored to your organization, add current Threat and Environmental metric values rather than relying solely on the published Base score.
Automate the tedious steps of vulnerability management with PDQ: an end-to-end patch management solution. Let PDQ inventory your software and flag vulnerabilities that you can patch, often in just one click. And should something go wrong with a patch (which would totally not be Microsoft’s fault, of course), use PDQ Connect’s built-in remote desktop control and access feature to get things back up and running again. Try PDQ free for 14 days.
