The 2020 and 10th edition of the Red Hat® Product Security risk report is an overview of security vulnerabilities that impacted Red Hat products for the 2020 calendar year. In this report, security vulnerabilities publicly announced throughout the last calendar year and the data and metrics produced for these vulnerabilities across all of our portfolios are reviewed. High-impact, high-profile events that affected Red Hat offerings and deserve more attention than many of the others are also reviewed.
In this report, product means a Red Hat offering listed at https://access.redhat.com/products and the associated version(s) available in 2020. All security related issues that impact one of those products are documented and assigned a Common Vulnerabilities and Exposures (CVE) identifier and a Red Hat severity rating by our Red Hat Product Security team. Red Hat Product Security includes Red Hat’s Product Security and Incident Response Team (PSIRT) that has been serving Red Hat, our subscribers, communities and partners since September 2001.
If we fix a general bug that later turns out to have a security implication, we retroactively assign a CVE name to that issue. Every fixed CVE has an entry in our public database in the Red Hat Customer Portal and a public bug report with more technical detail. In this report, we will use vulnerabilities and CVEs interchangeably. We report issues that represent a meaningful risk to users of our offerings and describe exploitable issues. Data used to create this report is available from public data collected and analyzed by Red Hat Product Security.
Every vulnerability reported to Red Hat Product Security is reviewed and analyzed by our team of open source security specialists. These engineers understand how our offerings are composed, curated, hardened, packaged, delivered, and used by our customers. This breadth of experience and insight into Red Hat product engineering’s security-focused supply chain practices helps provide critical insights into the potential impact of these vulnerabilities on our products and services.
Red Hat has more than 19 years of focused experience through the dedicated Red Hat Product Security team. We have worked through the evolution of physical servers, virtual machines, virtual images in the cloud, and the decomposition of legacy applications into microservices and containers, moving processing out to the edge and beyond. Along this journey, we have forged deep bonds with the open source community, which has earned us wisdom and insights into the challenges open source faces with security.
14+ years of reporting open source risk
Red Hat began reporting on the vulnerabilities discovered within components of our portfolio in 2005. Mark Cox authored a blog and later the Red Hat Summit presentation, “A Year of Red Hat Enterprise Linux® 4,” in the Spring of 2006. Back then, we recognized the need for providing Red Hat Enterprise Linux users with an idea of the potential severity and impact of a vulnerability. In his report, Mark also looked at the public exploits available, many of which were already being mitigated by security technologies built into RHEL such as stack protections and SELinux" In 2006, the Linux kernel had the most impactful vulnerabilities and still has the most impactful vulnerabilities to this day.
During this time, many major media outlets wrote articles asking “Which OS was better?”. These articles portrayed closed-source vendors favorably in their remediation of Critical vulnerabilities over open source software. This media attention spurred Red Hat to talk publicly and frequently about the real data around open source vulnerabilities.
In June 2007, Red Hat released the next major update of the report. Mark reviewed CVE data points and trends from the first three months after the Red Hat Enterprise Linux 5 release, and he recapped the first two years of Red Hat Enterprise Linux 4 risks.
Back then, we only had three Critical vulnerabilities to address in the release. Things were much simpler, with a handful of solutions to support and a relatively manageable volume of vulnerabilities to triage and analyze. The Red Hat Product Security team (then known as Red Hat Security Response team) only had seven people looking over about 25 products. While the team was very busy, addressing vulnerabilities was manageable with a small team of experts. Red Hat had been producing enterprise, open source software since 1993, but we only started publishing official security advisories in 1999.
When we released Red Hat Enterprise Linux 5.1 in November 2007, Mark revised the style by adding new piechart-free graphs and began creating the risk report to be what it is today. With each iteration, much like the open source code we support, the report became better and more useful, with interesting observations and insights. The message, “remaining vigilant and up-to-date,” was our charter for the report from the beginning. We realized that the open source ecosystem was constantly evolving and changing, and to keep our products resilient, we needed to track, document, and communicate.
In Spring 2008, we adopted the Risk Report title.