Open source projects can become victims of their own success. What can developers do to secure their open source software?

(This article was published in slightly different form for Black Hat 2020.)

One of the reasons behind the popularity of open source is the volunteer communities improving and updating code. It’s what software developer and author Eric Raymond called Linus’s Law in action: with many eyes looking at code, “all bugs become shallow.”

A Purdue University study showed that Linus’s Law does work. Open source communities regularly issue patches faster than their proprietary software counterparts. But Linus’s Law only works when there are enough eyes on the code. And there’s no guarantee that the community behind any given open source project will continue maintaining the code. Of the 1,200+ codebases examined for the 2020 Open Source Security and Risk Analysis (OSSRA) report, 88% contained open source components that had had no development activity in the last two years.

OpenSSL, Heartbleed, and developer burnout

OpenSSL, an open source encryption protocol, secures a substantial portion of the web: as much as two-thirds of all active websites, plus hundreds of thousands of email servers, chat servers, and VPNs, as well as the network infrastructure of various military, government, and financial institutions.

In 2011, a programming bug that could allow an attacker to intercept information secured by OpenSSL was introduced into the code, where it remained undiscovered for almost three years before being reported by a Google developer. Within 24 hours of its disclosure, the vulnerability, dubbed “Heartbleed,” was used to break into a major corporation and steal taxpayer data from the Canada Revenue Agency, according to a report in The New York Times. Although a patch was quickly issued, Heartbleed still lives on in hundreds of thousands of devices, with Shodan—an Internet of Things search engine—reporting over 91,000 instances of the vulnerability as of late 2019.

Steve Marquess, the former CEO of the OpenSSL Foundation, noted in a blog post that the coding error leading to Heartbleed was partially attributable to developer burnout. In 2011 there was only one overworked, full-time developer on the OpenSSL project. “There should be at least a half dozen full-time OpenSSL team members, not just one,” Marquess wrote. And that developer should be “able to concentrate on the care and feeding of OpenSSL without having to hustle commercial work.” Things have improved somewhat in 2020. There are now 18 contributors listed on the OpenSSL site and their work is funded through at least 2021, thanks to a grant from the Linux Foundation Core Infrastructure Initiative, a project dedicated to distributing resources to open source projects that are critical to the security of the internet. But the Heartbleed bug is what happens when people ignore the TANSTAAFL price.

The TANSTAAFL price

In the early 19^th century, “free lunches” were a popular saloon promotion. Patrons still had to buy a beer or other drink in order to wash down whatever food the barkeep offered, and that was the catch. Profits on whiskey and beer sales more than compensated the saloon for putting out the free lunch spread, which often was little more than soup, crackers, and problematic pickled eggs. Coined by science fiction author Robert Heinlein, TANSTAAFL (“There ain’t no such thing as a free lunch”) reminds us that things always have to be paid for, whether the price is evident or not.

With popular open source code, the TANSTAAFL price has been the increased pressure on its maintainers—the people who handle bug reports, feature requests, code reviews, and code commits for their “free” software. Increasingly, as open source use grows in popularity, the TANSTAFFL price has been developer burnout and their open source projects being abandoned.

It’s the tragedy of the commons in action—a resource growing so much in popularity that it can’t remain viable unless the community shifts to sustenance rather than exploitation. Witness the Twitter thread started by James M. South, creator of several popular open source solutions, who bemoaned the fact that, “#ImageSharp passed 6 million downloads this weekend and I’m a lot less happy about it than I probably should be.”

Why? South goes on in several follow-up tweets, “Over 5 years of development there have only been 98 collaborators, 23 of which have made more than 10 commits…. it’s not about money, it never was and never will be, it’s about sustainability.”

Several other developers chimed in with their experiences: “…a similar story for #FluentValidation. Over 41 million downloads … 140 contributors, but only 1 has made more than 10 commits.” “Same with ReportGenerator… 15 million downloads but not a single sponsor.”

Too few people—and their organizations—who rely on open source software are contributing to the projects whose open source they use. If you’re a developer and have a favorite open source component, you can contribute to its development through development, sharing your modifications, bug reporting, crowd-funding, letting the developers know how you are using it, and helping others get started. That last may be the most important thing you can do for any open source project—helping build a user community large enough to sustain the project.

While development support is important, it’s not necessarily just about the code. Whether you’re a writer, translator, designer, or information security or legal specialist, the chances are good that you too can help support the community in some fashion.

Download the 2020 Open Source Security and Risk Analysis (OSSRA) Report