Red Hat Product Security rates the severity of security issues found in Red Hat products using a four-point scale: Low, Moderate, Important, and Critical, as well as includes a separate Common Vulnerability Scoring System (CVSS) base score. 

The CVSS rating is not used to determine the priority with which flaws are fixed or to determine the severity rating of the vulnerability. It is used as a guideline to identify and describe key metrics of a flaw and is meant to help customers prioritize the order in which they remediate flaws. CVSS scoring is used by other agencies, which sometimes tend to score these flaws in a different way. 

The National Vulnerability Database (NVD) is a U.S. Government repository of vulnerability management data that includes databases of security checklists, security related software flaws, and impact metrics. NVD analysts calculate CVSS v3.1 score for each security issue and then apply the CVSS qualitative rating scale (Low, Medium,High or Critical) automatically based on the scoring.

For open source software shipped by multiple vendors, the CVSS base scores may vary for each vendor depending on the way the product is shipped in their platform, how it's compiled, and what configuration options are enabled by default. However NVD provides a single CVSS base score, which is product agnostic and sometimes, based on the above conditions, may differ largely from the scoring done by Red Hat for our products for the same security flaw.

Generally, we believe that Red Hat CVSS scoring is more accurate than the NVD score mainly for the following reasons:

  • Deeper Technical analysis of security issues: Most of the security flaws are deeply analyzed by security analysts at Red Hat. The more severe the potential impact, the more time spent on analyzing the flaw. Because of this, Red Hat often has a better understanding of risks and impacts associated with security flaws that affect its products.

  • Early access to flaw details: Some security flaws are reported directly to Red Hat by security researchers or users who discover the flaw. Security analysts at Red Hat are members of upstream security groups and projects and, therefore, typically work on security issues well before they are announced. Earlier access allows a thorough investigation, which helps Red Hat to have more information to develop CVSS metrics upon disclosure, as it pertains to the use of components in our products.

  • NVD focuses on the flaw as a worst-case in the broadest sense, regardless of compilation options or the operating system. Red Hat, on the other hand, individually scores the component based on the product it is used in and how it is built. This scoring means that in some cases, for example where a component is used in a very limited sense, it could have a lower CVSS score due to lower exposure (e.g. in Red Hat OpenShift) versus a more general or unknown exposure that is dependent on the customer's use (such as Red Hat Enterprise Linux). We note deviations in score and metrics, per-product, on the CVE page.  

Based on customer requests and taking the above information under consideration, Red Hat Product Security has begun a feedback loop process for security flaws that we feel have not been rated correctly by NVD. In cases where NVD agreed with our analysis, the scores were corrected and updated on the NVD web pages. Red Hat Product Security started this process as of 2020. For the last six months from April 14 to October 14, out of the 311 requests submitted to NVD for rescoring, 40% were accepted, 12% were rejected and 48% are still pending review.

Our improved security pages provide a detailed description of why our scoring is different to help customers understand their risk to that particular flaw. This detailed description helps to understand cases where the difference between the NVD and Red Hat scoring vastly differs based on the way NVD scores on specific ways that the software was compiled, configured, or shipped.

Overall our customers have told us that the CVSS re-score process with NVD has proven to be quite useful. They now better understand the impact and risks associated with security issues, based on how a specific component is consumed in the product they use.  It’s also helpful to the community, in general, as we strive to release as much of our research results as possible for the public’s consumption.

[Editor's note: Updated on October 14, 2020 for clarity.]


About the author

Huzaifa Sidhpurwala is a Principal Product Security Engineer with Red Hat and part of a number of upstream security groups such as Mozilla, LibreOffice, Python, PHP and others. He speaks about security issues at open source conferences, and has been a Fedora contributor for more than 10 years.

Read full bio