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.
저자 소개
Vincent Danen lives in Canada and is the Vice President of Product Security at Red Hat. He joined Red Hat in 2009 and has been working in the security field, specifically around Linux, operating security and vulnerability management, for over 20 years.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.