More money for open source security won’t work

Here’s the good news. According to the Open Source Security Foundation (OpenSSF), it will cost less than $150 million to secure open source software. More good news, industry giants Amazon, Intel, Google, and Microsoft have already pledged $30 million. Just $120 million to go toward a secure open source future, right?

Well, no, because the bad news is that no generalized approach to open source security is going to work. OpenSSF has a fantastic 10-point plan to foster a multifaceted approach to security. This approach has a better chance of succeeding than the more piecemeal approaches of the past, argued Brian Behlendorf, general manager of the OpenSSF, on a recent press call, because “there’s not one root cause or one root approach that’s going to address them all.”

He’s right, and it’s precisely why I worry that we may still be approaching open source security wrong.

But first, the plan

I don’t want to come across as disparaging these efforts. As I’ve written before, I’m optimistic. The OpenSSF’s attempts to rally the industry are an important upgrade on past approaches. The open source process by which we find and fix bugs is also the right way to tackle software security. The OpenSSF offers us a chance to coordinate our efforts.

I’m heartened by OpenSSF’s 10-point plan:

1. Offer security education for everyone working in the community
2. Establish a risk assessment dashboard for the top open-source components
3. Accelerate adoption of digital signatures
4. Replace non-memory-safe languages to eliminate the root cause of many bugs
5. Establish an open source incident response team
6. Improve scanning of code by maintainers and experts to find bugs more quickly
7. Conduct third-party code reviews of up to 200 of the most critical components
8. Coordinate industrywide research data sharing
9. Improve software bill of materials (SBOM) tools and training to drive adoption
10. Enhance the 10 most critical build systems, package managers, and distribution systems with better security tools and best practices

This is a smart, holistic approach to security and is yet another reason for developers to love open source. In fact, when I managed AWS’ Open Source Strategy and Marketing team, we commissioned a survey in 2020 to ask why developers like open source. Top of the list was security:

Chart courtesy of AWS

The developers responding to this survey knew about Heartbleed and other vulnerabilities in critical open source projects. They still picked open source. Thanks to the OpenSSF’s efforts, many more developers may be able to choose open source with added comfort.

Don’t assume this or any other funding will solve open source security problems, just as no amount of cash has made AWS, Google, or Microsoft impervious to software vulnerabilities. All software is buggy, now and forever.

Process is better than plan

The best guarantor of open source security has always been the open source development process. Even with OpenSSF’s excellent plan, this remains true. The plan, for example, promises to “conduct third-party code reviews of up to 200 of the most critical components.” That’s great! But guess what makes something a “critical component”? That’s right—a security breach that roils the industry. Ditto “establishing a risk assessment dashboard for the top open source components.” If we were good at deciding in advance which open source components are the top ones, we’d have fewer security vulnerabilities because we’d find ways to fund them so that the developers involved could better care for their own security.

Of course, often the developers responsible for “top open source components” don’t want a full-time job securing their software. It varies greatly between projects, but the developers involved tend to have very different motivations for their involvement. No one-size-fits-all approach to funding open source development works (though I continue to feel that the most sustainable open source has significant corporate involvement, whether from a community (Kubernetes) or a single company (MySQL/Oracle).

It’s also the case that hackers tend to be incredibly innovative in how they expose gaps in proprietary and open source software. It’s a virtual guarantee that they’re currently burrowing into components no one thinks are “critical” or “top” today but will become so when the software is compromised.

This is why I prefer the “meta” approaches in the 10-point plan, like replacing non-memory-safe languages (with things like Rust) or adopting digital signatures. These help build security into a project while deferring to the development process to fix bugs when discovered.

Let’s remember: As open source has grown in popularity, bugs have proliferated as WhiteSource and other firms have detailed. Think about that: The universe of open source code is expanding at a dramatic rate, and vulnerabilities have expanded in parallel. Identifying all those critical components in advance is a monumental and perhaps impossible task.

So, is the 10-point plan a waste? No. Not at all. But I worry that we’ll dupe ourselves into believing that $150 million is going to buy us open source security once and for all. It won’t. Even if it secured today’s components, we’d still need to have the industry upgrade old systems running older, less secure “critical open source components.” Hence, the only way for open source security to become real is for each individual project to take up the burden of security and take it very seriously, with each user of that project also taking it very seriously. The OpenSSF won’t deliver this for everyone, but if it helps, it’s $150 million well spent.