What Is CVSS? How to Read Scores and Prioritize Fixes

What Is CVSS

CVSS stands for Common Vulnerability Scoring System. It is a common standard for quantifying the severity of vulnerabilities in information systems. The U.S. nonprofit FIRST develops and maintains the specification. For public information in Japan, IPA and JVN assign CVSS scores when disclosing vulnerabilities. The primary source for the specification is FIRST’s published documentation (https://www.first.org/cvss/). Versions v2, v3.0, v3.1, and v4.0 exist. In practice as of October 2026, v3.1 and v4.0 coexist. v3.1 was released in June 2019 and was long used as the standard. v4.0 was released in November 2023 with expanded metrics.

The purpose of CVSS is to make the risk of each vulnerability comparable. Even when vendors and research institutions use different descriptions, they can be judged on a common scale. Scores are calculated on a scale from 0.0 to 10.0. The higher the number, the higher the severity. However, it is not an indicator that directly shows the scale of business impact. It is a yardstick for measuring ease of exploitation and technical impact on information assets.

The Three Metric Groups Behind the Score

CVSS v3.1 consists of three layers: Base, Temporal, and Environmental metrics. Base metrics measure characteristics intrinsic to the vulnerability. They cover technical elements that do not change over time. Temporal metrics reflect the availability of exploit code and whether fixes exist. Environmental metrics reflect the importance of the user’s assets and the state of countermeasures. Values published by NVD are centered on the Base score. JVN and vendors may also provide Temporal and Environmental scores.

The Base metrics include eight main items. They are Attack Vector, Attack Complexity, Privileges Required, and User Interaction. In addition, Scope and impacts on Confidentiality, Integrity, and Availability are included. Attack Vector has four levels: Network, Adjacent, Local, and Physical. Vulnerabilities exploitable over a network are rated higher. Conditions requiring no privileges and no user action are regarded as the most dangerous.

Temporal metrics consist of three items. They are Exploit Code Maturity, Remediation Level, and Report Confidence. The value rises when proof-of-concept code is published. The value falls when an official fix is provided. Environmental metrics take into account factors such as confidentiality requirements for assets. The same vulnerability has a different meaning for a financial institution and for a factory on an isolated network. It is a mechanism for reflecting that difference in the score.

In v4.0, the system was reorganized into Base, Threat, Environmental, and Supplemental metrics. Perspectives such as Attack Requirements, Safety impact, and Automatability were added. Safety harm for medical devices and industrial control systems can now be distinguished. With the finer granularity, greater proficiency is required from evaluators. Because of the transition period, dual notation with v3.1 is expected to continue for the time being.

How to Read Scores and Severity Ratings

Severity is divided into five levels by numerical range. 0.0 is None, 0.1-3.9 is Low, and 4.0-6.9 is Medium. 7.0-8.9 is High, and 9.0-10.0 is Critical. These ratings became established through NVD operations (https://nvd.nist.gov/vuln-metrics/cvss). The JVN Database (https://jvndb.jvn.jp/) also uses these ratings.

Results are expressed as a vector string. An example is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The attack vector is network and the conditions are simple. No privileges and no user interaction are required. Loss of confidentiality, integrity, and availability is all high. This combination scores 9.8 and is classified as Critical.

An operation that decides on immediate response based on the number alone is risky. Even a 7.5 may require immediate action if it affects an Internet-facing system. Even a 9.8 is lower in priority if there is no exploitation path within an isolated network. It is important to develop the habit of reading down to the vector string and confirming the exploitation path. In particular, check Attack Vector, Privileges Required, and User Interaction first.

How CVE, CWE, and CVSS Differ

CVE, CWE, and CVSS have different roles. CVE is an identifier assigned to each individual vulnerability. CWE is a weakness classification showing the type of vulnerability. CVSS is a score showing the severity of a vulnerability. The three are complementary and cannot replace one another.

A representative example is Log4Shell. Its identifier is CVE-2021-44228. Its weakness type is CWE-502, Deserialization of Untrusted Data. Its CVSS v3.1 Base score was calculated as 10.0. In practice, the standard flow is to identify the target with CVE, understand the cause type with CWE, and decide response order with CVSS.

Their use in operational documents is clear. Record the CVE number in the asset inventory. Cite CWE numbers in design guidelines and coding rules. Attach CVSS scores to monthly reports and response instructions. Listing all three together reduces rework. When vendor notices and NVD values differ, keeping both makes root-cause tracing easier.

Prioritizing Vulnerability Response in Practice

In the field, CVSS scores are used for initial triage. Asset criticality and exploitability are then factored in. The standard procedure has four steps. First, cross-reference the asset inventory with the exposure scope. Second, perform an initial screening by CVSS score. Third, adjust for observed exploitation and reachability. Fourth, assign deadlines and owners.

Thresholds for initial screening are set by each organization. As an example, Critical is started within 24 hours and High within 7 days. Medium is within 30 days and Low is at the next maintenance. However, items such as an unauthenticated management interface exposed to the Internet are escalated. Cases on a closed network with multi-factor authentication are de-escalated. Uniform operation by numbers alone leads to incorrect responses.

Complementary indicators of exploitability are important. EPSS shows the probability of exploitation in the next 30 days. CISA’s KEV catalog is a list of vulnerabilities confirmed to have been actually exploited. Many organizations treat KEV-listed items as top priority regardless of CVSS score. SSVC is a framework for deciding responses based on exploitation status and impact on human life. Cross-checking CVSS, EPSS, and KEV is the realistic solution.

The key to running the operation is how records are kept. Summarize the CVE number, CVSS score, vector, asset name, and exposure scope in one line. Even when judged as not requiring action, keep the reason. The practice of declaring no fix needed or not affected in VEX documents has also become widespread. Combined with SBOM, it speeds up identification of the impact scope. It also fulfills accountability for audits.

Limitations of CVSS and Preventing Misuse

CVSS does not reflect business context. Revenue impact and recovery costs are out of scope. Scores before exploit code is published may come out lower than the actual harm. Scores vary by about 0.5 depending on the evaluator. This is the main cause of discrepancies between vendor and NVD values.

There are three common misuses. First, leaving Medium and Low unattended. There are combinations that turn into High when chained. Second, uniform ticketing based only on Base scores. If Environmental metrics are neglected, response breaks down. Third, confusing v3.1 with v4.0. Because the items differ, they cannot be directly compared. It is necessary to strictly indicate the version.

Editorial Opinion

For comparison, the evaluation criterion should be impact on the organization’s own assets and exploitability, rather than the level of the Base score. CVSS shows the conditions for successful exploitation, but does not show downtime or the volume of leaked information. Evaluations combined with EPSS and KEV listing status should be emphasized. The pitfall in the field is leaving discrepancies between vendor-calculated and NVD-calculated values unaddressed. Preconditions vary by evaluator, and there are cases where the same CVE differs by 0.5 or more. Rather than easy automatic ticketing, operation corrected with Environmental scores is essential. The future direction is likely toward standardization of combined use of CVSS v4.0 with SSVC and VEX. With wider SBOM adoption, asset identification will accelerate, and combining severity with reachability will become mainstream. The shift from single-indicator reliance to composite judgment will advance.

References

• FIRST CVSS v3.1 Specification (https://www.first.org/cvss/v3.1/specification-document)
• FIRST CVSS v4.0 Specification (https://www.first.org/cvss/v4.0/specification-document)
• NVD Vulnerability Metrics, NIST (https://nvd.nist.gov/vuln-metrics/cvss)
• JVN Database (https://jvndb.jvn.jp/)
• IPA Vulnerability Information Related to CVSS (https://www.ipa.go.jp/security/vuln/CVSS.html)
• CISA Known Exploited Vulnerabilities Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog)