The Open Source Security Foundation was a long time coming

The Open Source Security Foundation (OpenSSF) is a few months old now, but the question is why it isn’t years old. After years of attackers exploiting bugs in OpenSSL, Apache Struts, and countless other projects, along with our laziness in patching them, it seems that long ago we would have combined to protect the open source supply chain upon which every organization depends. But we haven’t. It wasn’t until 2020 that we decided as an industry to stop piecemealing our approach to security.

Why?

That’s the question I asked Kim Lewandowski, a Google product manager and member of the OpenSSF’s governing board. According to Lewandowski, “We all depend on open source, and there’s no reason for us to all try to solve this individually or in a silo.” She’s right, but why did it take us so long to get to this point?

You and you and you and…

One of the problems with open source security is that it’s not any one company’s problem. Goldman Sachs, for example, wants the software on which it depends to be secure, but why should it bear the brunt of paying to secure software that everyone uses? Ditto Google, which has contributed and uses a great deal of open source software. As Lewandowski stated, “Google is not going to go in and rewrite every single open source software package that exists on the internet today that our customers and we are using.”

Even if Google wanted to do so, it really couldn’t. There’s simply too much. Sure, the company could fix OpenSSL or Apache Struts or whichever project is currently compromised, but the universe of open source code is gargantuan and always expanding.

This simply isn’t a task that any one company can reasonably tackle alone.

Different projects, different needs

This fact is complicated by the diverse needs of each project. According to Lewandowski, each project is different and as convenient as it would be to throw money at the security problem, that doesn’t necessarily work. “We’ve seen some maintainers where they don’t want the money, or can’t take the money, or simply can’t apply it for things that we need.”

Other projects need help with security audits, which the OpenSSF plans to enable. Such audits currently take place within the CNCF and other foundations or organizations, but they’re incomplete as they are. According to Lewandowski, “The audits we’ve seen have been great and have uncovered a lot of things, but then the projects can get stuck with a bunch of work that needs to be fixed if [the auditor] doesn’t see [the audit] all the way through” to remediation. And sometimes, she continued, “Folks will fix bugs just to pass the audit or as a quick fix and the deeper underlying security issue is still there.”

So how can a community rally to not only find but also fix problems?

Lewandowski explained that the OpenSSF is currently considering different models to engage contributors to help resolve security vulnerabilities. It turns out it’s not necessarily straightforward, however. Some organizations, for example, want to contribute the expertise of their engineers to help fix the bugs, which is great, but how can OpenSSF hold them accountable? If a number of member organizations pledge five engineers each, for example, “How do you show accountability such that all of those engineers are doing exactly what we hoped they would do inside the Foundation?” These are tough problems, and more help is needed.

Despite the daunting challenges, progress is being made. In partnership with ISRG, for example, the popular cURL is getting a new back end written in Rust that promises to deliver even better security. Such a collaboration is a great example of the kind of thing OpenSSF can foster.

But why did it take so long?

Better late than never

“It’s kind of eerie how many similarities you can draw to the current pandemic,” Lewandowski pointed out. “It’s like no one really cared to do too much about it until there’s this huge outbreak impacting us all.” While there wasn’t any trigger event for OpenSSF, there has been a steady drumbeat alerting us to the need for years. From time to time, we’ve reacted. The Heartbleed rupture of OpenSSL, for example, gave rise to the Core Infrastructure Initiative, led by the Linux Foundation. Similar objectives arose elsewhere in response to different threats.

Even so, they were still largely siloed efforts.

Some of those silos spring from companies running open source in (periodically not so blissful) ignorance. Organizations might think they’re paying for proprietary software but, as WhiteSource and others have highlighted, upwards of 95 percent of all software includes open source components. No matter what the outward license, there’s open source inside. Always.

This fact is starting to sink in, making now the perfect time for the OpenSSF to make a significant impact on the industry. Of course, as Lewandowski stressed, “It’s a delicate balance on how you talk about it. You want to drive awareness, but you can’t scare everyone away.”

So let’s say it this way: Open source is foundational to all software today, which software increasingly powers even the most remote aspects of our lives. The process behind open source — the process by which we find and fix bugs — is the right way to tackle software security, but it can be that much better if we coordinate our efforts. The OpenSSF offers us a chance to do that, and needs involvement not just from software vendors, but also from companies like JP Morgan Chase, Facebook, Uber, and, hopefully, you.

Read more about open source:

• Stargate: A new way to think about databases
• Why open source needs more cloud
• Are you sure you want to open source that project?
• The year of PostgreSQL is every year
• Does Snowflake mean the end of open source?