Depending on Open Source software is Risky Business (and Heartbleed proves it!)

Depending on Open Source software is Risky Business (and Heartbleed proves it!)

By all accounts, Heartbleed is the worst security flaw in the history of the Internet.  What it is and why it is so bad has been talked about ad nauseum, so I won’t bore you with those kinds of details, but here are a couple places to learn more about it if you are not already up to speed.  Randall Munroe from xkcd.com painted the picture in laymen’s terms.  Matt Smith describes here how a bug this nasty could live unnoticed in the wild for a couple years.

The thing is… I want to talk about why those of us who are responsible for bridging the gap between technology and business are crazy when we recommend that our companies use Open Source software for critical functions in our organizations without a thorough risk assessment.  “How is Heartbleed and indictment of Open Source software?” you may ask.

Well, I think there are two key reasons that it’s too risky to depend on Open applications in the business where I work.  You get to decide if you are comfortable with the risks for your business.

Lack of Accountability

A popular phrase around our office is “One Throat to Choke”.  We use it in reference to businesses that have too many vendors providing related services – when there is a problem, the vendors point fingers at each other and say “it’s their fault.”  Businesses with too many vendors often want to replace the multiple vendors with one, and that gives them “one throat to choke”.

When you select an Open Source application to provide critical functionality and a problem comes up, you have “no throat to choke”.  Because you have paid no one for their work, there is no one to hold accountable for solving a problem.

The OpenSSL folks did a great job validating and fixing Heartbleed in only a few days.  But what if they did not?  What if it had taken a week… or two… or a month?  Or what if they decided it was too much work and they did not want to fix it?   How much havoc could have occurred if the team didn’t have the time or inclination to resolve Heartbleed quickly?  None of the millions of non-contributing OpenSSL users would have a reasonable complaint against OpenSSL, because they did not paid for anything, and made no agreement with OpenSSL that the product would function securely or correctly.

Lack of Resources

As I read Matt Smith’s account of how Heartbleed could happen, I was pretty surprised to learn that both financial and human resources are so scant for the OpenSSL project.  OpenSSL has never grossed more than $1 million in a year.  They have only one full-time dedicated worker on the team.  The rest of the team is comprised of part-timers, mostly volunteering.  In spite of the fact that most of the servers hosting sensitive content on the internet depend on OpenSSL, virtually no one has supported the project either financially or as developers.

With a team that small, it is not surprising that a nasty bug like this got past code review.  I believe the risk of that kind of bug getting through code review in a larger, well-funded development team is much smaller.

I would expect more bugs like this one in the future, except maybe there’s a little good news for OpenSSL.  Some big players are stepping up to help them.

This is great for OpenSSL, but I wonder… what other critical and widely used Open Source applications have yet undiscovered bugs due to lack of funding and manpower.  Which of your critical systems is depending on those Open Source applications with bugs?

I worked for a large corporation for much of my career.  The company had (and still has) a vendor management team whose job it was to perform a risk analysis prior to doing business with any particular vendor.  There is no way I would have been able to convince the vendor management team that it would be an acceptable risk to use a vendor so under-resourced as OpenSSL.

And yet, because it is “free”, OpenSSL and other Open applications like it have permeated our corporate environments without the same risk assessment that would come with commercial software. Now you know why I think long and hard (and perform a careful risk assessment) before recommending Open Source applications to the business I work for or our clients.

On a side note, people who are part of the Open development community deserve our gratitude for their innovation and desire to collaborate with their fellow humans by making their wares available without high costs.