There has been a great deal of media attention around Heartbleed, the recently revealed serious security flaw affecting large swaths of the Internet. But because the vulnerability exists in OpenSSL — an open source implementation of SSL encryption — some industry pundits have been debating whether open source is to blame for Heartbleed. Others, on the other hand, suggest that the security flaw was spotted only because of open source’s benefits: the fact that a community of inspired developers can scan and review the code with frequency.
The Heartbleed bug affects a function called Heartbeat, which is essentially a frequent questions/answer exchange between a user’s machine and a website in order to keep the communication going. For this purpose, random data packets were to be exchanged. It turns out that a hacker can force the so-called random packets coming from a user machine to actually contain confidential information.
Robin Seggelmann, who submitted the buggy code, admitted that he “missed the necessary validation by oversight.” What’s more, the bug wasn’t spotted during the review process for OpenSSL, a project that is written and reviewed by a community of programmers.
Despite that oversight, proponents of open source technology say that the Heartbleed open source security vulnerability was only exposed because of the community of programmers that were able to review the source code. In a proprietary environment, such a bug could have remained hidden. Recent studies confirm this claim.
Although open source has a slightly better track record than its proprietary counterparts, it is inevitable that security vulnerabilities will arise. Given the vast number of open source packages that are available today, keeping track of these open source security vulnerabilities can be a daunting task. That’s where the National Vulnerability Database (NVD) comes in.
The U.S. Department of Homeland Security created the database in 2005 in response to the growing tide of security vulnerabilities. The data essentially includes the description of the discovered vulnerability, its exploitability, the severity level (on a scale of 1 to 10) and its potential impact, and the workaround to be applied over the vulnerable system. Organizations can leverage the information in the NVD when they encounter open source security vulnerabilities in their code.
How can organizations keep their code safe?
The key to mitigating risks from open source security vulnerabilities is to understand code composition and to have a clear picture of open source content in a software portfolio. This can be particularly challenging given the complexity of modern codebases and the widespread use of open source code, since developers do not usually track which open source files or code snippets they include in their projects. Also, many organizations do not have a formal preapproval process in place for open source packages.
There are a number of best practices that organizations can follow to ensure they keep track of their code content. These open source governance practices are sometimes referred to as an open source software adoption process. A typical modern open source adoption process usually includes the formation of an open source policy, a process for approving open source code before it enters the development environment and a way to detect open source policy violations in real-time, complemented by regular open source audits.
An open source policy defines which open source packages or package attributes are acceptable for use in the organization. Packages with known open source security vulnerabilities of a certain severity level should be prohibited as a starting point in drafting an open source policy. The open source policy will form the foundation the rest of the adoption process will rely on. With an open source policy in place, organizations can assess the suitability of various open source software files for their organization and business practices.
An open source policy steers preapproval of specific open source content in a project. It also establishes the metrics to accept or reject open source content that is discovered in a software portfolio before the product is shipped to the market. Any open source code detected through a manual audit process or through automated scanning solutions can be examined to see whether a CVE (Common Vulnerability and Exposure) has been issued against it. While a manual security vulnerability audit suffices for a small project, larger software projects can only be effectively assessed using automated solutions.
Automated open source scanning tools employ deep-scanning techniques that compare code against a large reference database of hundreds of millions of public-domain software files and look for similarities. Any file or snippet similar to open source software is then flagged. Open source scanning tools also tie into the NVD and can inform the users automatically when new vulnerabilities are reported against code in their portfolio.
The use of open source code is an excellent way to speed up development and reduce development costs when used correctly. High profile security vulnerabilities like Heartbleed should not scare organizations away from leveraging open source software in their products. Implementing a process to adopt and manage open source and using automated open source scanning tools that tie into the NVD can make remedying any issues fast and easy. With full knowledge of all open source and third-party code in a software portfolio, organizations can isolate open source security vulnerabilities easily and implement open source governance more effectively.
Lacey Thoms is a marketing specialist and technical blogger at Protecode, having written many articles on open source software management. Follow @Protecode on Twitter.