How the rise of open source could improve software security

Openness by itself does not yield more secure code, but a new dependence on open source by major software players could ensure more rigorous scrutiny

One of Jim Zemlin’s top priorities for 2015 is security. As executive director of the Linux Foundation, his purview extends beyond Linux to Cloud Foundry, Open Daylight, Tizen, Xen, and many more -- including the Core Infrastructure Initiative formed in response to the hellacious HeartBleed vulnerability in OpenSSL discovered last year. The hourlong conversation I had with Zemlin last week began and ended with discussing that initiative.

We all know the Heartbleed saga: The flaw stood unaddressed for two years until Neel Mehta of Google Security found it in March. A patch was made available almost immediately. But tracking down and patching all those OpenSSL instances took months, and over time evidence surfaced of breaches related to the flaw, including one at Community Health Services that reportedly affected 4.5 million people.

As Zemlin acknowledges, "many eyes" -- the proposition that open code vetted by a community is inherently safer than closed source -- failed. A big part of the problem, notes Zemlin, was that the OpenSSL project was maintained by "two guys named Steve" (independent consultants Dr. Stephen Henson and Steve Marquess) who possessed specialized knowledge of encryption and presided over a project containing several hundred thousand lines of code. How many pairs of eyes would have the stamina, let alone the expertise, to vet all that code?

Six months later, admins everywhere were confronted with the nasty Shellshock bug, which had apparently lurked in the open source Bash project since 1989. Two brutal black eyes in such a short span made 2014 a very bad year for open source security. Yet at the same time, open source emerged in 2014 more clearly than ever as the engine of innovation for software. Could the need for software security be any greater?

Credit Zemlin with jumping on Heartbleed fast. In the wake of the disaster, he quickly formed the Core Infrastructure Initiative and signed up Amazon Web Services, Adobe, Bloomberg, Cisco, Dell, Facebook, Fujitsu, Google, Hitachi, HP, Huawei, IBM, Intel, Microsoft, NetApp, NEC, Qualcomm, Rackspace, Salesforce, and VMware -- all of which pledged to contribute $100,000 annually for a minimum of three years.

With those funds Zemlin has been able to "employ the Steves full time" (actually Dr. Henson and Andy Polyakov) to work on OpenSSL. As part of the initiative, the Open Crypto Audit Project is conducting an ongoing security audit of the OpenSSL code base.

In other words, the OpenSSL project -- which previously averaged $2,000 a year in donations -- has landed in a sort of corporate embrace. The eyes may not be legion, but more of them are taking a hard look, with a vested interest in ensuring the security of the code.

The group around OpenSSL assembled in response to disaster. But over the past few years, high-impact open source projects (think Docker or Kubernetes) have been garnering the support of industry heavyweights at a very early stage, while others -- such as OpenStack or OpenDaylight -- actually began as consortiums. OpenStack, for example, has its own Vulnerability Management Team and Security Group.

Does that mean such "serious eyes" projects are producing perfectly secure code? Of course not. Getting developers to take security seriously has always been a struggle, not simply due to lack of interest but also because stringent security and usability always stand at odds. However, I think the recent, early-stage "corporatization" of hot open source projects could make it less likely that underresourced yet vital projects like OpenSSL will languish -- and emerge as security liabilities down the road.

Whatever you think of CoreOS's Rocket challenge to Docker, for example, I find it encouraging that CoreOS chose to go after Docker primarily on security grounds. No doubt CoreOS knew that argument might resonate, though Docker saw its 1.0 release only last June.

Let's hope this is a virtuous cycle. Every industry heavyweight including Microsoft now sees the power and benefit of open source's high-velocity innovation. True, the big incumbent software players don't exactly have sterling security records, either. But increasingly, the entire industry realizes it can move much faster if it collaborates in developing and supporting base-level open source technology development so that individual vendors can differentiate on top. This collaboration may well result in more secure software than any one vendor could accomplish.

Based on what I've read over the years, you can't make the generalization that either open source or proprietary software has a leg up in security. What I'm hoping is that serious commitment to open source projects by multiple commercial players could help raise software security overall. At the very least, open source projects embraced by corporate confederations should produce better security outcomes than two guys named Steve can accomplish on their own.

Copyright © 2015 IDG Communications, Inc.