The history of open source risk reporting

This year Red Hat released our 10th Product Security risk report, which reviews the vulnerabilities that affected our products during the previous year. Software, and our customers’ environments, have gotten more complex — and so has the IT security landscape. 

With so much information on Common Vulnerabilities and Exposures (CVEs), our users have found it helpful to have one source of information about the risks posed to Red Hat technologies. And because Red Hat offers a full portfolio of technologies beyond Linux, we’ve expanded and improved the risk report to better reflect the issues that our customers care about. Now, let’s take a brief history lesson about how open source risk reporting has changed over the years.

In the beginning...

Back in days of yore there was a boy named Linus Torvalds. He wrote some software he loved very much called Linux. He loved it so much he shared it with the world and people also loved it and started to build upon it, which was cool. That software grew into a movement and ecosystem that makes up to as much as 80%-90% of modern enterprise software today. 

Sadly though, software is created by humans, and humans sometimes make mistakes. These mistakes can sometimes be found by people with nefarious intentions and exploited for their own benefit. OSS project teams and groups like Red Hat Product Security work hard to address those bugs that have security repercussions.

Open source security in the 2000s

2005 was full of “Hollaback” moments, saw the Sith getting some revenge, we learned about truthiness, U2 had a new album, and a sixth visit to Hogwarts was shared with the world. 

Not to be outdone, Red Hat introduced the world to some open source magic as we described a Year of Red Hat Enterprise Linux 4 in our first ever risk report! It was later shared at our 2006 Red Hat Summit and helped describe to consumers what vulnerabilities impacted that software during its first year of operation. During that first year, we fixed 422 vulnerabilities. RHEL4 also marked the introduction of our Red Hat Severity Ratings to assist end-users in understanding which of those advisories mattered most.

The next time readers would get such a report was in 2007, where we started to talk about the first 3 months of Red Hat Enterprise Linux 5 (RHEL5) and we released a second report for RHEL 4. This year would prove pivotal for open source. UNIX copyright holder, SCO, filed for bankruptcy, and Microsoft released the latest version of their operating system, Windows Vista. SCO had long grappled with the up-and-coming open source movement. Another minor footnote to history is that a small technology company out of Cupertino California released something called the iPhone that changed the trajectory of the technology. 

Stumbles in major technologies furthered the acceleration of open source adoption while the tectonic shift of computing from data centers to cloud-based apps that could be accessed from anywhere played right into the agile, ever-evolving open source ecosystem, trends that ultimately got reflected back into the risk report.

2008 saw the adoption of the moniker “Red Hat Risk Report” and we started blogging more frequently to address industry-spanning challenges around vulnerability scanners and the security of “third party applications”. Throughout 2009 and into 2010 the report continued on in this manner. 

Mid-2010, however, we introduced our on-going conversations around Common Weakness Enumeration (CWE) with the “Red Hat’s Top 11 Most Serious Flaw Types for 2009” report, which you will still see today in our current reports. 

By reviewing the CWEs that are related to the CVEs within a component, we’re able to help identify chronic coding mistakes and help work with developers on techniques and actions they can take to avoid reproducing them.

The Red Hat Risk Report expands its scope

As newer versions of our products were released, the scope and scale of the components included within them grew. Risk reports that previously only covered kernel and networking flaws now reflected the more varied spectrum of packages our enterprise customers demanded. In 2011 four Risk Reports were issued targeted on specific updates of Red Hat Enterprise Linux and this pattern was followed throughout the next several years. In August 2013 however, we published our first “risk report” on Apache Tomcat and JBoss.

2015 was a landmark year for Red Hat Product Security. It was the first year we released a  combined product Risk Report and it was the start of our long-standing conversation around “branded flaws.” The 2015 edition of the report became the template for the reports that followed, and the following year it was transformed into a “leave behind” whitepaper-style artifact you can access now.

As we stated at the beginning of this review, we’ve seen and learned a lot in our 20-plus years of securing open source software and throughout our 14-plus years of writing about threats, vulnerabilities, and risks that Red Hat subscribers could face (as well as providing practice advices about what to DO about those problems). 

We hope you’ve enjoyed our reminiscing tour of the history of the Red Hat risk report, and we hope you enjoy the 2020 report itself and all the insights it offers you. We’ll next be writing about those pesky branded flaws that cropped up in 2020 and some trends we’ve recognized in trying to reduce the fear, uncertainly, and doubt around them over the years.

If you are interested in reading more about what Red Hat Product Security works on, you can access all of our blogs through the Red Hat Product Security Center and the monthly archives found there as well as on the Red Hat Blog security channel.