Understanding CVEs and CVSS Scores
What's the difference between CVE vs. CVSS scores?
CVSS scores are a shorthand way to communicate the severity of known vulnerabilities (CVEs) so that users can take steps to protect and secure their systems. But how are CVSS scores calculated and what do the different scores mean?
In this blog, our expert explains how vulnerabilities are assigned CVSS scores, the most common CVEs, and the importance of patch management protocols — especially when using end-of-life software that is no longer supported.
- What Is a CVE Score?
- CVE vs. CVSS: What’s the Difference?
- How Are CVSS Scores Determined?
- What Are the Most Common Types of CVEs?
- How Should CVEs Be Patched?
- Final Thoughts
What Is a CVE?
CVE is short for Common Vulnerabilities and Exposures. Once a CVE has been identified, it is added to the CVE database, which is a glossary of all known vulnerabilities.
CVE vs. CVSS: What's the Difference?
The CVE represents a summarized vulnerability, while the Common Vulnerability Scoring System (CVSS) assesses the vulnerability in detail and scores it, based on several factors. It is important to note that a CVSS score is not a calculation of risk, but rather a qualitative measurement of severity, from low to critical.
CVSS scores are recorded by the National Vulnerability Database (NVD). The CVSS is maintained and updated as needed by FIRST, a U.S.-based non-profit organization.
Here's how CVSS scores are defined by the NVD:
A CVSS score is represented as a vector string, or a compressed textual representation of the values used to derive the score. Thus, CVSS is well-suited as a standard measurement system for industries, organizations, and governments that need accurate and consistent vulnerability severity scores.
CVSS scores are typically used to help organizations prioritize remediation based on the severity of the vulnerability.
How Are CVSS Scores Determined?
There are three types of metrics used to determine CVSS scores:
Base Score Metrics
Base metrics represent the essential characteristics of the vulnerability that remain constant over time and regardless of user environments. Base metric scores range from 0 to 10 and are comprised of two subsets of metrics: Exploitability and Impact metrics.
Exploitability metrics refer to the technical ease and the method by which the vulnerable component can be exploited. Vulnerable components are often software applications, modules, drivers, or hardware devices.
The Impact metrics, on the other hand, consider the consequence of a successful exploit — the effects on the impacted component. Impacted components tend to be software applications, hardware devices, or network resources. Consideration for the impacted component, in addition to the vulnerable component, was a welcome new feature that was introduced with CVSS v3.0.
Within the Base metrics group, there are the following sub-categories: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality Impact, Integrity Impact, and Availability Impact.
Temporal Score Metrics
As the name suggests, temporal metrics reflects the characteristics of a vulnerability that may change over time, but is not affected by different user environments. Temporal metrics build on the Base metric score by factoring in the following three sub-categories: Exploitability, Remediation Level, and Report Confidence. The existence of a simple-to-use exploit kit, for instance, would increase the CVSS score, whereas the availability of an official patch would lower it.
Environmental Score Metrics
The characteristics of a vulnerability that are specific to the user’s environment fall under the Environmental metric group. Examples include security controls that could mitigate the negative impact of a successful attack, or how important the vulnerable system is relative to the user's technology infrastructure.
Sub-categories of this group include Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality Impact, Integrity Impact, Availability Impact, Confidentiality Requirement, Integrity Requirement, and Availability Requirement.
What Are the Most Common Types of CVEs?
The most common types of vulnerabilities are Code Execution, Denial of Service, Cross Site Scripting (XSS), and Overflow, followed by Gaining Information, Sql Injection, and Bypass.
The OWASP TOP 10, which tracks vulnerability trends, shows an uptick in the last few years in Broken Access Controls, Cryptographic Failures, and Security Misconfiguration and a major increase in Vulnerable and Outdated Components.
How Should CVEs Be Patched?
As best practice, organizations should have a maintenance plan in place for different risk response scenarios. It's also wise to adopt a phased roll-out for routine patch deployments so you can identify issues and minimize disruptions in a small subset of assets before you scale. This is how most organizations test patches.
This approach enables you to detect problems early and plan an alternate response (like a temporary migration) if necessary. It's important to remember that a patch may break more than it fixes at first glance. If early phases indicate the patch will have low operational impact, you can then expand the patch to more, or all, of the vulnerable assets iteratively.
In some cases, it may make sense to do several rounds of testing, especially for patches that will directly impact those outside the organization, i.e. customers. The first round could roll out only to a select number of system administrators and engineers. A few days later, you could expand the patch to others in the organization who are willing to be guinea pigs, so to speak, and report any issues they encounter. This is a useful way to get feedback and work out the kinks before widely releasing the update.
When a CVE has a very high likelihood of adversely affecting an organization's business, an accelerated Emergency Patching schedule should be adopted. Deciding when this applies is largely a calculation of risk appetite; each organization makes on its own.
Based on the performance of the phased roll-outs and the criticality assessment (a.k.a. is it an emergency or not), a Vulnerability Mitigation Time Summary can then be created incorporating KPI targets, Key Risk indicators (like a sudden drop in the rate of updates installed), and lessons learned (i.e. improvements to the maintenance schedules).
Many, if not most, security breaches occur from known vulnerabilities being left unmitigated, which underscores the importance of a mature patch management process like the one described above. When a technology or framework becomes end of life, however, the situation becomes more complex since patches will no longer be provided by the software developers.
The 2023 State of Open Source Report revealed that end-of-life (EOL) software sometimes exists in organizations longer than it should. For example, 15% of organizations are still using AngularJS more than a year after it reached end of life. Running unsupported EOL software is always risky, so it's critical for organizations to get long-term support through a vendor like OpenLogic as they take steps to migrate to a newer version — or in the case of AngularJS, to one of the AngularJS alternatives.
Running EOL CentOS or AngularJS and Worried About CVEs?
Reduce your risk with dependable long-term support from OpenLogic. We provide security patches and other fixes to keep your apps safe from CVEs while you plan your next steps. Learn more via the links below.
- Blog - What Is the Securing Open Source Software Act?
- Blog - Debunking Open Source Software Security Myths
- Blog - Why Companies Choose OpenLogic for Support
- Guide - What Is Enterprise Application Security?
- White Paper - What You Need to Know About AngularJS EOL
- On-Demand Webinar - How to Minimize Risk After Open Source EOL