Why My Heart Bleeds for Open Source

When it comes to development, do you take the open-source software (OSS) or commercial off-the-shelf (COTS) software road? It’s a discussion that fills forums, blog posts, and water cooler conversations everywhere.

You’ll hear developers tell you that open source is the answer every time. First, developers have the flexibility to examine the code and make sure it's not doing something they don’t want it to do. They can then change the bits they don't like. Second, the accessibility of open-source code means it is quicker to learn, and students can quickly study it as they learn to make better software.

Third, there are so many developers typically working on a piece of open-source software that it can be fixed, updated, and upgraded more quickly than proprietary software. Finally, the source code for open-source software is publicly distributed, which helps ensure the tools won’t disappear overnight or fall into disrepair. All resounding reasons for standardizing your business development on open source.

Remember Heartbleed?

I’m not so sure.

My anxiety about pinning 100% of your development on open source code can be summarized in one word: Heartbleed. Remember that? No, let me re-phrase that — who can forget this car crash moment for open source back in 2014?

Heartbleed is a security bug in the open-source library OpenSSL, which is designed to encrypt communications between a user’s computer and a web server. Introduced into the software in 2012, the Heartbleed bug compromises the private key used to encrypt traffic between client and server. Once compromised, usernames, passwords, and other secure data can be decrypted and stolen without leaving a trace. This allows attackers to eavesdrop communications and steal data that can then be used to impersonate services and users.

At the time, the security expert Bruce Schneier described Heartbleed as “catastrophic.” He added, “On the scale of one to 10, this is an 11.”

It gets worse.

It is widely alleged that the National Security Agency (NSA) knew about the Heartbleed Internet security flaw two years before it was publicly known and reported in 2014. The NSA not only said nothing about the serious bug that compromised the OpenSSL encryption library used by millions of websites, but it also used the bug to gather intelligence.

Mix and Blend

Don’t misunderstand me here. I’m not suggesting open-source software is the devil in disguise. What I am advocating is that organizations should take a balanced approach to development code, using a blend of both open-source and COTS software in their development strategy.

Risk Management

For COTS software, customers vote by their dollars, not downloads. If a software bug or glitch causes a problem to a business, that business has a vendor to hold accountable and potentially liable. Who does a business hold accountable or liable for an OSS bug? The answer is no one.

In 2014, the Wall Street Journal reported that the bulk of the OpenSSL project was managed by four European coders and a former military consultant in Maryland. A total of 11 people (10 volunteers, one full-time person) worked on the project, with most of the volunteers too busy with their day jobs to concentrate consistently on the project. The bottom line is this: If your company is 100% or too heavily reliant on OSS, you are exposing your business to risk.

In 2014, CIO.com stated that though some research shows that OSS may contain fewer defects than proprietary code, OSS code rarely benefits from security teams specifically tasked with looking for bugs. Zack Samocha, senior director of products at Coverity was quoted as saying, “A typical proprietary software company will have a security team that ensures that best practices are carried out. They have the budgets to maintain those teams. I don't see those entities…in the open-source community.”

Heartbleed was just one of four high-profile OSS bugs to hit the news in 2014. All four sat around for years before they were fixed. OSS doesn’t undergo the same rigorous tests as commercial software, and your business is dependent on a bunch of hobbyists or enthusiasts to monitor and fix bugs.

This fact brings up an additional risk for the enterprise. Support for OSS projects can become trendy where enthusiasm wanes as popularity decreases. For example, just four years ago, Subversion was the code repository of choice; now, GitHub is the new shiny object being used for everything. Who will be there to support your OSS code in three to five years? COTS software vendors have a financial interest in maintaining and even modernizing their code base. If their developers become bored with the code base, they can leave the vendor for greener coding pastures, but that turnover is the vendor’s problem, not yours. That OSS developer fickleness can quickly become your problem.

Moreover, since a developer’s career experience directly impacts the salary they can command, they are frequently financially incentivized to use the latest OSS library, whether it is a company standard or not. This can contribute to the ever-present threat of shadow IT at your organization which places the burden of patching and updating OSS libraries on your Operations teams; developers are not always diligent in ensuring shadow IT projects are properly patched and updated. Your entire environment could be susceptible to hacks.

Please don’t consider me too pessimistic or downright negative toward OSS. I’m not. In fact, I use a lot of OSS myself. I am simply trying to raise awareness to the risks enterprises assume without realizing they are assuming them. OSS is a fantastic resource, but it is not nirvana nor the enlightened path to the next level of digital enlightenment. OSS, like COTS software, has upsides and downsides. We must be wise stewards of our digital domains. It is my advice to think in terms of using both in order to mitigate risk while accelerating agility. After all, no business wants to be exposed to a threat like Heartbleed, Goto Fail, Shellshock, or Poodle again.