Glibc Vulnerability

Glibc Vulneratiblity – Don’t Drown

Posted on Posted in Cybersecurity, security vulnerability

The recent highly critical open source software vulnerability glibC affecting many devices highlights the need for strategic management of open source software.

Glibc Severe Vulnerability in one of the Internet's Core Building Blocks

On February 16th 2016 a Google engineer discovered a security vulnerability which potentially could affect hundreds of thousands of devices, applications and services. On investigation the vulnerability was found in the GNU C Library (glibc). The vulnerability has a "Common Vulnerabiltites and Exposure" (CVE) number of CVE-2015-7547 details of which can be found on the National Vulnerability Database.

Security vulnerabilities are nothing new and they can be present in any component of software, whether proprietary or open source. But the process and strategies for managing the risk of vulnerabilities will differ between proprietary and open source software.
A patch has now been issued for the glibc component in question and is available here. However if an organisation is unaware the component is in their application then there could be a vulnerability that could be exploited at any time.

The "Future of Open Source Survey" run last year by open-source proponent Black Duck Software, found that 78 percent of respondents use open-source software, two-thirds build customer software using open-source components, and 55 percent see security as the most important reason to embrace open source. Just 17 percent of those companies, however, said they actively monitor for open-source security vulnerabilities.

So what is the best approach?

Reactive - An organisation that has no formal open source software policies and processes in place means stakeholders will be highly unlikely to have any awareness that these vulnerabilities exist and furthermore will also not understand the related business risks of exploitation. In the reactive mode, even if there is awareness that the vulnerable code is present, the cost of mitigating the risk will have a heavy operational and business impact in the form of cost and risk exposure.

Proactive - A formal open source software policy is in place combined DevOps processes and procedures that are communicated across all relevant stakeholders across the organisation. All open source code is tracked and inventoried so if a vulnerability is posted all stakeholders not just development are automatically alerted to its presence in their source code and the severity rating of the vulnerability. It should be possible to identify where in the source code the component is, and trigger a DevOps process to update the source code and deploy the fix to the end customer/user install base. More importantly, all stakeholders from senior management to software development teams will have immediate visibility of the issue which will ensure that the appropriate actions are taken to mitigate the risk.

DevOps and Open Source Software Continuous Compliance 

The process Source Code Control advocate to our clients is a system of "Continuous Compliance" in line with an organisation's open source software policy. Without a clear policy which is communicated across the organisation, issues will be missed leaving organisations exposed to exploitation of security vulnerabilities. Policies should be integrated across all stages of DevOps processes to ensure issues are dealt with immediately, thereby ensuring the best protection from related business risks.

Leave a Reply

Your email address will not be published.