In ages past, invading armies would poison the water source – usually a well – of a city in order to reduce the fighting capability of the enemy or to force the populace of a city under siege to surrender. This method was usually successful because an invader could have a devastating effect on a very large population with minimal yet targeted effort.
But only if the poison wasn’t discovered in a timely fashion.
Like the community well, open source is open for everyone to use—and use it we do. According to North Bridge’s Future of Open Source 2015, 78 percent of businesses run on it, which indicates both participation in and use of open source is on the rise.
However, open source is not just big projects or complete software. Many projects are libraries like OpenSSL and AFNetworking; libraries that are used extensively by other projects – commercial and open source; software meant to be used within other software.
OpenSSL, for example, is embedded everywhere. It’s part of Apache, it’s part of Nginx. According to the latest Netcraft Web Server Survey, that means 52 percent of all websites include OpenSSL. The open source AFNetworking library is used by a variety of iOS developers to quickly add networking capabilities to iOS apps, including some very high-profile, popular apps, such as Citrix OpenVoice Audio Conferencing, Alibababa’s mobile app and Movies by Flixster.
Both open source libraries appear to have poisoned the well of projects they feed.
Cult of Mac reports that SourceDNA recently uncovered a weakness in AFNetworking library that enables man-in-the-middle (MITM) attacks. In April 2014, a vulnerability in the OpenSSL cryptography library was disclosed and subsequently given the moniker “Heartbleed.” And then, of course, there’s FREAK, also known as OpenSSL CVE-2015-0204.
In fact, according to Bill Ledingham, CTO at Black Duck Software, 40 percent of the 8,000 vulnerabilities disclosed last year were in open source projects. The software upon which (it turns out) a whole of organizations depend on is, all too often, insecure. It contains vulnerabilities that may lie dormant for years (and years and years) but upon discovery can have devastating effects due to its expansive use.
…Can. Possibly. Potentially. But hasn’t…
Two high-profile breaches have been blamed on Heartbleed, resulting in significant costs for the organizations in question for breach notifications and an incalculable loss of trust and reputation. According to Dark Reading, three of foyr global 2000 companies are still vulnerable to Heartbleed one year after its discovery. We should totally be as afraid as the headlines promoted by #hashtag tell us we should be.
And yet we aren’t, or at least we don’t appear to be based on North Bridge’s results. According to that research, 55 percent of respondents said open source delivers superior security and nearly half (46 percent) give preference to open source security solutions over proprietary ones. A look to OSS in general before any other software.
Turns out the well is not so poisoned after all. It’s not even really tasting all that bad.
Why is that? Perhaps it’s because risk is not just the presence of vulnerabilities but about the probability of exploitation. Because even though approximately 52% of the web servers were vulnerable, just 17% were exploitable at the time of Heartbleed’s coming out party. Many of those that were vulnerable were safely ensconced behind infrastructure that was not vulnerable. There were load balancers and proxies in front of them that prevented (and still prevent) the vulnerability from being exploited. Of those that were vulnerable, many were subsequently patched or otherwise protected and only a handful were actually successfully exploited.
Perhaps it’s because open source communities have proven very responsive to vulnerabilities. Heartbleed was patched within a week of disclosure, and software reliant on the OpenSSL libraries were quickly updated and pushed out with great alacrity. That’s not just because open source developers are highly aware of their credibility (it’s their name on that code, after all) but because a significant number of commercial and corporate organizations alike use and contribute to that source code, making it – as the term community implies – a shared concern. When a vulnerability is discovered, the entire community goes into overdrive.
Perhaps it’s because for every open source security vulnerability we find we can find one on the proprietary side, too. The flip side of Ledingham’s statistic is that 60 percent of vulnerabilities reported last year were not in open source. After all, D-Link routers are still vulnerable to a remote access exploit as of this writing. You know how to use Google, so I won’t bore you with a complementary non-open source list. Choosing proprietary solutions does not guarantee a solution free of vulnerabilities.