Open source security is a major topic of discussion in the IT industry today. A series of incidents have raised concerns about the viability of open source software and its ability to adequately protect sensitive corporate assets.
The most recent and serious example is Shellshock. Since its discovery a few months ago, it has become increasingly clear that Shellshock represents a major threat to countless organizations and individuals. The vulnerability, which affects the widely used Bash software offering, is built into more than 70 percent of Internet-connected machines, The New York Times reported. Thanks to Shellshock, hackers may be able to gain complete control over these devices. This makes Shellshock potentially even more devastating than Heartbleed. These two events together have led many industry observers to criticize and doubt the general effectiveness of open source security.
However, many others believe that neither Shellshock nor Heartbleed suggest the need for a major reconsideration of open source's security capabilities. On the contrary, these events suggest not flawed fundamentals, but rather a lack of open source security resources.
The shallow bugs theory
One of the famous sayings in the realm of open source software is "given enough eyeballs, all bugs are shallow." This suggests that open source can be more secure than proprietary solutions, as the sheer number of programmers and other users will eventually ensure that any coding issues are identified and corrected. In light of these recent open source security problems, though, certain observers have called this belief into question. If all bugs are shallow, how do you account for Heartbleed and Shellshock?
Writing for Tech Republic, industry expert Matt Asay argued that these fears are overblown and misguided. He acknowledged it is true that Bash, OpenSSL and other open source programs became widespread without anyone identifying serious flaws until recently. However, this does not prove that the "enough eyeballs" theory is wrong. After all, this dictum does not say anything about catching open source bugs early, it simply suggests that enough attention paid to a piece of open source software will identify all of its bugs and lead quickly to solutions.
The problem with these and other vulnerabilities is that not enough eyes were applied to the code until after the vulnerabilities were discovered. The shallow bugs theory wasn't proven wrong – it simply did not come into play.
The real lesson that organizations should take from these incidents, according to TechTarget's Brandan Blevins, is that they should devote more resources toward achieving open source security. Blevins noted that before the discovery of the Heartbleed vulnerability, the OpenSSL Software Foundation received only approximately $2,000 annually in donations, according to the organization's co-founder, Steve Marquess.
"In spite of the fact that virtually every high-tech company in existence relies on OpenSSL, virtually none of them had any contributions towards its maintenance," said Neil Watson, a senior partner with Evolve Thinking, Blevins reported. "You get these very important projects that are [in] many cases just taken for granted, and we just assume they work. No one helps them at all."
Consequently, OpenSSL, Bash and other open source projects remain heavily dependent on volunteers to ensure their security. This limits the reliability of these offerings.
After Heartbleed, many major companies pledged millions of dollars to this foundation in order to help ensure the security of OpenSSL's code. These firms depend heavily on OpenSSL in their own operations and consequently have a vested interest in keeping it safe. It took Heartbleed for them to recognize that more resources were needed to achieve this goal.
This logic should apply to organizations themselves, as well. Firms that want to take advantage of open source's inherent benefits should also take steps to shore up their own approach to security in this area. For example, one key component of effective open source security is knowing exactly where open source is running throughout an organization, especially when open source code is so easy to obtain by anyone in the organization. To this end, firms should embrace high-end scanning solutions that can search the corporate code base comprehensively.
Additionally, organizations should dedicate the resources needed to deploy effective governance and support tools that can cut down on security risks. Underappreciating internal open source security on the assumption that these solutions are heavily vetted externally is an easy way to put a company at risk of a breach.
• Watch this free webinar to learn top tactics to reduce your open source security risk
• Read this white paper for steps you can take to protect your organization from open source vulnerabilities