Do all vulnerabilities really matter?

Vulnerabilities in software are a global concern, and open source software is no different from proprietary software in this regard. Any software vulnerability has the potential to be exploited by miscreants to harm its user. Whether this is on-premises, in the cloud, or on your mobile device, vulnerabilities in software make headlines (for good reason).

There is tension, however, between software producers and software users. On the surface, any vulnerability is scary due to the potential for harm. Yet, the reality is that most vulnerabilities have minimal opportunity to cause harm, whether due to the type of vulnerability itself, the type of authorization required to execute it, the vulnerability’s level of exposure in typical use of the software, and many other factors. This variability means a vulnerability in a particular component used in different products could result in different severities in those products. All software vulnerabilities are not created equal, and there is a substantial body of work to support this assertion.

For instance, Red Hat produces an annual Product Security Risk Report highlighting the number of vulnerabilities found and fixed in Red Hat products. The 2021 Product Security Risk Report identified 1596 vulnerabilities affecting the Red Hat product portfolio. At the time the report was released, only 26 of those vulnerabilities were identified as being actively exploited, according to the Cybersecurity and Infrastructure Security Agency (CISA). While this is just one source of data, this widely utilized source provides insight into observed exploitation at scale. Incidentally, the vast majority of exploited vulnerabilities in CISA’s catalog are in proprietary software.

And most security breaches against entities are not due to software exploitation. The 2022 Verizon Data Breach Investigations Report noted that only 7% of breaches were due to software exploitation. The vast majority were due to credential theft and phishing attacks; as they note, 82% of breaches were due to the “human element” and not software. The data isn’t there, but one must wonder what percentage of that 7% was in software with an available patch that hadn’t been applied?

We will release the 2022 Product Security Risk Report early next year, but thus far, the indicators are primarily the same. Most breaches are not due to software vulnerabilities, and most software vulnerabilities are not exploited.

To be crystal clear: there are vulnerabilities that must be fixed. And they need to be fixed in a reasonable amount of time to enable end-users to apply mitigations to avoid potential exposure. However, given the number of vulnerabilities discovered annually, remediating every single one is a daunting task for anyone, whether a vendor, an upstream community, or a downstream consumer. This is why no vendor fixes every known vulnerability as an immediate priority. From a scaling perspective, it’s prohibitively expensive. There is an adage: if everything is important, then nothing is. This is especially true when it comes to risk management.

From an innovation perspective, it means resources that could be advancing technology are used to correct vulnerabilities that will likely never be a cause for concern. The promise of open source is innovation, which is what most open source communities and commercial providers seek to provide. So, time spent fixing issues that introduce little risk versus creating new and innovative solutions is an interesting dilemma.

Red Hat is no different. Our customers engage with us for digital transformation and speed of innovation, using our technologies to help them with solutions that create ever greater value for their customers. This is why we defined robust product life cycles that clearly indicate what Red Hat will and will not fix in terms of security vulnerabilities.

We know that, statistically speaking, Critical vulnerabilities are those most likely to be exploited and those most likely to cause significant harm if successfully exploited. At all points in the product life cycle, we fix Critical vulnerabilities as quickly as possible. In 2019, we extended this to all Important-rated vulnerabilities across the product life cycle. These are vulnerabilities that, while not as damaging as those rated Critical, could still cause significant harm if exploited. To put it in perspective, in 2021, of the 10 Critical CVEs affecting the Red Hat portfolio, only one was on CISA’s list of known exploited issues (or 10%), and of the 283 Important CVEs, only seven were on CISA’s list (or 2.5%). Even here, we see that the observed active exploitation is low. Still, because it’s difficult to determine which ones will end up being actively exploited, from a proactive and protective perspective, we fix them all.

While fixing Moderate and Low severity issues are not part of the published product life cycle, they may be fixed when other non-security fixes are published. This reduces the burden of testing by the end user – after all, most enterprise customers test fixes before deploying in production—a cost borne by the end user for every update. When this becomes too expensive, these updates simply won’t be applied in a timely fashion. We want our updates to be applied as quickly as possible!

As we monitor vulnerability exploitation, our commitment is to correcting risky vulnerabilities. Red Hat aims to promote effective risk management, and we will fix all actively exploited vulnerabilities, irrespective of severity.

It’s simple economics. A Moderate vulnerability being exploited still only provides a certain level of exposure, typically less than a Critical or Important vulnerability, or requires a significant amount of effort to be successful. Consider this example. In 2021, there were 1060 identified Moderate vulnerabilities, of which only 18 (or 1.7%) were identified as being actively exploited, and Red Hat responded as quickly as possible to these issues when observed. Developing fixes for all 1060 vulnerabilities, when only 18 were impactful, is a significant undertaking; each one must be created and tested by the vendor and further tested and deployed by the consumer. That isn’t cost-effective or risk-appropriate for either party.

When updating any software, there are costs in time and resources, as well as risks to interoperability and security. We employ risk mitigation strategies for those updates by focusing on providing updates for what, based on the information available, truly matters. Software updates are typically produced through backporting. This reduces the number of code changes needed to fix the issue and minimizes the introduction of new, currently unknown vulnerabilities that may become present in later versions.

We aim to take a pragmatic, trusted and resilient approach to vulnerability management in our products. Moreover, our approach reflects the true value of open source – the collaborative and speedy approach to innovation and value creation.

If you want more details on how Red Hat handles vulnerabilities and our methodology, read our recently-updated whitepaper: An Open Approach to Vulnerability Management.