Understanding CVEs and CVSS Scores

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).

Final Thoughts

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.

CentOS Support        AngularJS LTS