What Is Common Vulnerability Scoring System (CVSS)?
Written By
Sarwat Iftikhar
The Common Vulnerability Scoring System (CVSS) is a standardized framework for assigning a numeric severity score to software vulnerabilities. Scores range from 0.0 to 10.0, where higher numbers indicate greater severity. A CVSS score of 9.8, for example, signals a critical vulnerability that requires immediate attention. A score of 3.1 signals a low-severity flaw that can be addressed in a future maintenance cycle.
CVSS was developed to give security teams, vendors, and organizations a shared language for describing vulnerability severity. Before CVSS, different researchers, vendors, and tools described vulnerability severity using inconsistent terms and criteria. A flaw that one researcher called critical might be described as moderate by another. CVSS replaced that inconsistency with a defined calculation methodology that produces a reproducible score from a fixed set of inputs.
This post covers how CVSS scores are calculated, what the score ranges mean, how the Base, Temporal, and Environmental metrics differ, why a CVSS score is not the same as risk, how security teams apply CVSS in practice, and what changed with CVSS 4.0.
Key Takeaways
- CVSS scores range from 0.0 to 10.0 and classify vulnerability severity across five bands: None, Low, Medium, High, and Critical
- Scores are calculated from a defined set of metrics covering attack vector, complexity, required privileges, user interaction, and impact on confidentiality, integrity, and availability
- The Base Score describes intrinsic severity; Temporal and Environmental scores adjust it for context, including whether an exploit is available and what the affected system means to a specific organization
- CVSS measures severity, not risk; a 9.8 vulnerability on an isolated internal system can carry lower actual risk than a 6.5 vulnerability on a public-facing API
- CVSS 4.0, released in 2023, added a new Threat metric group and refined scoring to address gaps in how supply chain and OT/ICS vulnerabilities were handled
What Is CVSS and Who Maintains It?
CVSS is maintained by FIRST, the Forum of Incident Response and Security Teams, a non-profit organization that coordinates incident response and security best practices across industry and government globally. FIRST released CVSS v1.0 in 2005, CVSS v2.0 in 2007, CVSS v3.0 in 2015, CVSS v3.1 in 2019, and CVSS v4.0 in October 2023.
The National Vulnerability Database (NVD), operated by NIST, assigns CVSS scores to every published CVE. When a vulnerability is assigned a CVE identifier, NVD analysts score it using the CVSS framework and publish the score alongside the CVE record. These scores are the ones most security tools, scanners, and patch management platforms pull when displaying vulnerability severity.
CVSS scores can be assigned by multiple parties. A software vendor may publish their own CVSS score for a vulnerability they disclose. A security researcher may publish a score alongside their findings. NVD publishes its own scores independently. When scores differ between sources, the differences usually reflect different interpretations of the environmental context or updated information about exploitability.
CVSS is the scoring standard that connects individual vulnerability findings to vulnerability management programs at scale. Vulnerability management platforms ingest CVE data with CVSS scores attached, and security teams use those scores as an initial filter for prioritizing which vulnerabilities to address first.
How Are CVSS Scores Calculated?
CVSS scores are not assigned subjectively. They are calculated from a defined set of inputs called metrics. Each metric has a fixed set of possible values, and each value contributes a numeric weight to the final score. CVSS v3.1, still the most widely deployed version, uses eight Base metrics.
Attack Vector (AV) describes how an attacker reaches the vulnerable component. Network-reachable vulnerabilities score higher than vulnerabilities that require physical access. The values are Network (highest weight), Adjacent, Local, and Physical (lowest weight).
Attack Complexity (AC) reflects whether the attack requires conditions beyond the attacker’s control. A vulnerability that can be exploited by sending a single crafted request scores Low complexity. A vulnerability that requires a race condition or specific configuration to be in place scores High complexity.
Privileges Required (PR) captures whether the attacker needs any authentication before exploiting the vulnerability. None scores higher than Low (limited privileges) or High (administrative privileges).
User Interaction (UI) describes whether exploitation requires a human to take an action, such as clicking a link or opening a file. None scores higher than Required.
Scope (S) indicates whether exploitation of the vulnerable component can affect components beyond its own security boundary. A vulnerability that achieves impact only on the targeted component is Unchanged. One that can affect other components or systems is Changed, which increases the score significantly.
Confidentiality Impact (C), Integrity Impact (I), and Availability Impact (A) each capture the severity of impact on the affected system’s data confidentiality, data integrity, and system availability. Each can be None, Low, or High.
Bugstrix vulnerability assessment engagements score every finding using these same metrics, giving clients a reproducible severity classification that maps directly to NVD scoring. Findings are then sorted by CVSS score as a starting point for vulnerability assessment and remediation planning.
What Do CVSS Score Ranges Mean?
CVSS defines five severity bands. Each band carries a conventional remediation priority, though the actual timeline should be adjusted by environmental context.
Critical (9.0-10.0) vulnerabilities are typically network-exploitable, require no authentication, require no user interaction, and produce significant impact on confidentiality, integrity, or availability. Unauthenticated remote code execution vulnerabilities commonly score in this range. These findings require immediate response.
High (7.0-8.9) vulnerabilities are serious and exploitable under realistic conditions, but require some constraint: authentication may be required, user interaction may be necessary, or impact may be limited to one dimension (e.g., confidentiality only). SQL injection vulnerabilities and privilege escalation flaws frequently score here.
Medium (4.0-6.9) vulnerabilities require more conditions to exploit, such as local access, specific configurations, or interaction from a privileged user. They represent real security risk but can typically be addressed through normal development cycles rather than emergency response.
Low (0.1-3.9) vulnerabilities have limited practical exploitability or impact. Physical access requirements, multiple conditions needing to align, or low-impact outcomes push scores into this range. They are tracked and remediated, but not prioritized over higher-severity findings.
Zero-day vulnerabilities frequently score Critical or High under CVSS Base metrics, because they are discovered precisely when they meet the conditions that make exploitation feasible.
What Is the Difference Between CVSS Base, Temporal, and Environmental Scores?
CVSS v3.1 produces three types of scores, and each answers a different question.
The Base Score describes the intrinsic characteristics of the vulnerability itself, independent of time and organizational context. It captures how exploitable the vulnerability is and what impact successful exploitation would have. Base Scores are the scores most commonly published, referenced, and compared across organizations. Because they strip out context, they allow apples-to-apples comparison of vulnerability severity across different environments.
The Temporal Score adjusts the Base Score based on current real-world exploitability factors. Three metrics contribute: Exploit Code Maturity (is working exploit code publicly available?), Remediation Level (has the vendor released a patch or workaround?), and Report Confidence (how certain is the vulnerability report?). Temporal Scores are lower when the vendor has released a patch or when exploit code is only theoretical. They rise when active exploit code is circulating. Temporal Scores are updated over time as the situation around a vulnerability evolves.
The Environmental Score adjusts the score for a specific organization’s context. Security teams apply Environmental metrics to reflect how much they actually care about confidentiality, integrity, and availability for the affected system, and to capture whether the Base metrics accurately reflect their deployment. A vulnerability that scores 8.9 on a Base score may score 4.2 Environmental if the affected component is isolated from sensitive data and has compensating controls in place.
Understanding the difference between Base and Environmental scores is directly relevant to the comparison between vulnerability assessment and penetration testing. Vulnerability assessments typically produce Base Scores from scanner output. Penetration testing produces contextual findings where testers evaluate actual exploitability within the specific environment, which informs a more accurate Environmental Score.
How Does a CVSS Score Differ From Actual Risk?
CVSS measures severity. It does not measure risk. This is one of the most frequently misunderstood aspects of how CVSS works, and acting on Base Scores as if they represent risk leads to poor prioritization decisions.
Risk combines severity with likelihood and business impact. A 9.8 CVSS vulnerability on a development server with no network access and no sensitive data carries different risk than a 6.5 vulnerability on a public-facing API that handles payment processing. CVSS cannot capture that distinction because it does not know what the affected system does or who can reach it.
Attack surface context changes the risk picture. An internet-facing web application carrying a Medium CVSS vulnerability that allows unauthenticated file upload is more urgent than a Critical CVSS vulnerability that requires physical access to a device stored in a locked data center. CVSS assigns the latter a higher Base Score, but the business risk calculus is the opposite. Attack surface management provides the external exposure context that turns a CVSS Base Score into an actionable risk ranking.
Remediation capacity is finite. Organizations with hundreds or thousands of open findings cannot remediate all of them simultaneously. Using Base Score alone as a prioritization signal will generate queues full of technically severe vulnerabilities in low-exposure contexts, while contextually critical findings in external-facing systems wait. Risk-adjusted prioritization requires combining CVSS severity with asset criticality, external exposure, and compensating control data.
The Environmental Score is the bridge between severity and risk. Using Environmental metrics allows security teams to formally encode their asset criticality and control posture into the scoring framework. A finding with a 9.5 Base Score on a system classified as non-critical with compensating network controls may recalculate to a 5.2 Environmental Score, accurately reflecting the organization’s actual exposure.
How Is CVSS Used in Security Testing and Vulnerability Management?
CVSS scores appear at multiple stages of a mature security program, from initial testing through remediation tracking and ongoing exposure management.
In penetration testing, CVSS scores provide a consistent severity classification for every finding in the report. Rather than leaving severity to subjective language (“this is serious”), a CVSS score communicates severity in a format that development teams, risk managers, and executives can interpret using a shared reference point. Bugstrix penetration testing reports include CVSS v3.1 scores for every finding, with explicit documentation of each metric value so clients can verify the scoring and apply Environmental adjustments for their specific context.
Understanding how penetration testing works clarifies why manual tester judgment still matters alongside CVSS scores. A skilled tester may find a logic flaw that technically scores Medium on CVSS metrics but is trivially exploitable in the specific application context and leads to full account takeover. CVSS scores findings; they do not replace the judgment of the tester who found them.
In vulnerability management programs, CVSS scores are the primary input for remediation prioritization queues. Vulnerability scanners pull NVD scores for every CVE they identify and sort findings by severity. Security teams work from the top of the queue down, addressing Critical and High findings first. Continuous Threat Exposure Management (CTEM) frameworks go further, using CVSS severity alongside threat intelligence, asset exposure data, and compensating control information to produce a risk-adjusted prioritization that reflects the actual threat landscape rather than static severity bands.
In SLA and compliance frameworks, CVSS score thresholds are used to define remediation deadlines. A common framework defines: Critical findings remediated within 24 hours, High within 7 days, Medium within 30 days, Low within 90 days. Formalizing these commitments with CVSS thresholds creates measurable remediation KPIs.
Get a quote for a penetration testing or vulnerability assessment engagement
What Changed in CVSS 4.0?
CVSS 4.0 was released in October 2023. It retains backward compatibility with v3.1 in broad terms but makes significant structural changes to how scores are calculated and what they can capture.
The Temporal Score group was renamed to Threat. In CVSS 4.0, the Threat metric group captures whether exploit code exists in the wild. FIRST simplified the group to a single metric: Exploit Maturity. This replaces three v3.1 Temporal metrics (Exploit Code Maturity, Remediation Level, Report Confidence) with a more direct measurement of real-world exploitation status.
The Supplemental metric group was added. CVSS 4.0 introduces a fourth metric group, Supplemental, which captures additional context that does not affect the numeric score but provides useful qualitative information: safety implications, automatable exploitation, recovery time, value density (how much value an attacker gains per successfully compromised instance), and vulnerability response effort. These are informational, not score-modifying.
OT/ICS and safety-critical system support was improved. CVSS v3.1 was designed primarily for IT vulnerabilities. CVSS 4.0 added safety-related scoring context to better reflect vulnerabilities in industrial control systems, operational technology, and safety-critical applications where availability and safety impact differ from conventional IT risk models.
Scoring nomenclature changed. CVSS 4.0 uses a naming convention to communicate which metric groups were applied to a score: CVSS-B (Base only), CVSS-BT (Base + Threat), CVSS-BE (Base + Environmental), CVSS-BTE (all three groups). This makes it immediately visible whether a published score reflects raw severity or has been adjusted for threat and environmental context.
CVSS 4.0 adoption is growing but CVSS 3.1 remains more prevalent in scanner output, NVD records, and security tooling as of 2026. Coordination through responsible disclosure channels increasingly involves CVSS 4.0 scoring as vendors update their vulnerability handling processes to the new standard.
Frequently Asked Questions
Who assigns CVSS scores to vulnerabilities?
CVSS scores can be assigned by multiple parties. NVD (National Vulnerability Database) scores every published CVE. Software vendors often score vulnerabilities they disclose directly. Security researchers publish CVSS scores alongside their findings. When scores from different sources differ for the same vulnerability, the differences reflect different metric interpretations or additional context one party had that another did not.
Is a 10.0 CVSS score always the most urgent vulnerability to fix?
Not necessarily. A 10.0 CVSS score means the vulnerability has maximum theoretical severity based on its intrinsic characteristics. Whether it is the most urgent fix depends on whether the affected system is reachable, what data or functionality it hosts, and whether compensating controls are in place. Risk-adjusted prioritization combines the Base Score with asset criticality and exposure context to produce a more accurate remediation queue.
What does a CVSS vector string look like?
A CVSS v3.1 vector string encodes every metric in a compact format. For example: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H represents a network-exploitable vulnerability with low complexity, no privileges required, no user interaction, unchanged scope, and high impact on confidentiality, integrity, and availability. This produces a Base Score of 9.8. Vector strings allow anyone to review and verify the scoring, rather than accepting a final number without seeing the inputs.
How often are CVSS scores wrong or disputed?
CVSS scoring involves judgment on metrics like Attack Complexity and Scope, which can be interpreted differently. NVD acknowledges scoring discrepancies through its “NVD Score” and “CNA Score” distinction, where the original assigning organization and NVD sometimes publish different values for the same CVE. Disputes are more common for vulnerabilities where the exploitation conditions are unclear at the time of disclosure and are updated as more information becomes available.
Does CVSS work for all types of vulnerabilities?
CVSS works best for discrete software vulnerabilities with clear exploitation paths. It is less well-suited for configuration weaknesses, insecure design patterns, and business logic flaws, which may have significant real-world impact but produce low or moderate CVSS scores because they require specific knowledge of the application to exploit. CVSS 4.0 made improvements for OT/ICS and safety-critical contexts, but the framework remains most precise for conventional IT software vulnerabilities.
What is the difference between CVSS and CVE?
CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a specific vulnerability. It is a label and a reference, not a score. CVSS is the scoring framework that assigns a severity score to a CVE. A CVE has one identifier and may have multiple CVSS scores from different sources. CVSS and CVE work together: CVE identifies what the vulnerability is; CVSS describes how severe it is.
CVSS as a Foundation, Not a Ceiling
CVSS provides something the security industry needed: a shared, reproducible language for describing how severe a vulnerability is. The framework has its limits, and those limits are worth understanding. A CVSS score is not a risk assessment. It does not tell you whether a vulnerability is being actively exploited, whether your specific deployment is affected, or whether the business impact in your environment justifies emergency response. Those judgments require context that CVSS intentionally excludes from its Base Score calculation.
What CVSS does provide is a defensible starting point. Security teams that understand the scoring framework can read a Base Score and know exactly which conditions produced it, apply Environmental adjustments to reflect their actual exposure, interpret Temporal and Threat scores to factor in current exploitability, and communicate prioritization decisions in a format that other teams and stakeholders understand.
Bugstrix works with organizations to build vulnerability management programs that use CVSS correctly: as a severity signal that feeds into a broader risk model, not as a standalone ranking of what to fix. That means combining CVSS scores with asset criticality, external exposure mapping, threat intelligence, and compensating control data to produce prioritization that reflects actual business risk rather than theoretical severity.
