Who Owns Open Source Security?

According to a recent report by the Internet Security Forum, open source software (OSS) is quickly becoming a pillar within enterprise infrastructure. In fact, OSS is now used in 99% of commercial codebases. Given this increase in popularity, engineering teams must make OSS security a priority. But, beyond managing the internal impact on a specific organization, an important question is whether companies, OSS communities or both should “own” the management of an open source project’s security. Put in relationship status terms, it’s complicated.

OSS can be complex for many reasons. Vulnerabilities can exist within the open source project’s own codebase or within the software’s dependencies. Often OSS projects are made up of third-party open source components that need regular updates. Outdated dependencies increase the potential attack surface for hackers, which means a zero-day could be lurking anywhere. Not to mention, complex community and corporate dynamics can muddy the waters of open source security ownership.

The Open Source Community’s Responsibility

The community’s responsibility to an open source project includes maintaining updates, whether they’re major upgrades or more regular, minor patches. However, the issue of maintainer burnout in open source is real. In many communities, the economics of maintaining open source software aren’t sustainable for its key contributors (or the communities themselves).

A textbook example is the now-infamous Heartbleed bug in OpenSSL. OpenSSL is an integral part of encrypted communications on the web, yet was maintained by only a few people (only one of whom was employed full-time). Even though the software was widely used by many corporate contributors who could have given back to its maintenance, the massive exploit remained undiscovered and spread throughout the web at a breakneck pace. One positive outcome is that Heartbleed shed light on the issue of maintainer burnout and led to more corporate funding for the project.

Some larger communities, by contrast, have more funding and active contributors to fix security issues as they arise. These communities have the advantage of “many eyes” on finding vulnerabilities. What one person or group misses, another will likely find. The subsequent disadvantage, though, is that with group work comes group thought. Security by committee can sometimes lead to a diluted solution that sums up to the least common denominator that all parties can agree to.

Encouraging Corporate Open Source Citizenship

Beyond the community alone, if companies are using OSS, they should contribute back to the project’s security. It all comes down to being a good corporate open source citizen. The corporation is benefitting from the work of dozens, sometimes hundreds of open source contributors. They owe the community an obligation to contribute when and where they can.

For example, if companies find OSS bugs, they should contribute the fixes back to the community. This level of radical transparency can be difficult when it comes to reporting security issues, but it’s a critical part of being a good corporate open source citizen. If companies commit a percentage of their developers’ time to maintaining OSS security, they can prevent potential vulnerabilities from being exploited—both within their four walls and within the community as a whole.

An Ideal Setup: A Collective Security Approach

In a perfect world, open source security is a partnership between open source communities and their corporate compatriots, much like a public/private partnership. Some larger communities, such as Drupal and Linux, do well at encouraging these partnerships. Ultimately, it comes down to giving these collective security “owners” the tools, funds, resources and training they need to proactively address open source security.

Tools could include automated security updates from the community itself, CI/CD tooling that automates security, or commercial OSS support. Funding and resources could mean financial donations to open source foundations or security projects, or paid time for employees to devote to open source security. For example, corporate contributors could participate in security and feature-testing research to become visible and vocal parts of the community.

Finally, training in secure coding best-practices is essential and widely available from resources such as the SANS Institute. This training ensures that security is integrated throughout the development life cycle, both for the OSS projects themselves and the companies that use them.