Column Open source software has always been more secure than proprietary software, but that doesn’t mean it’s “secure”. To lock it down, we have to invest a lot of money in developers and maintainers.
You may have noticed that many people receive seriously grumpy about the security of open source software lately. They have a reason. Our bullshit has been in the news a lot lately.
To name a few, there were Log4j vulnerability patches in progress; the bad npm code injection fiasco; and you haven’t heard of the latest Linux PolKit security flaw since many embedded systems will never be patched.
So what can we do about it? First of all, as I like to remind people, if you think open source security is bad, it’s only because you never hear about security from obscure errors from proprietary software until that they explode or that they are corrected. Just look at Microsoft’s endless Patch Tuesday issues where patches can be just as bad as the original issues.
But, just because closed-source developers have their problems doesn’t mean it takes away our faults. On the open-source side, we need to do better soon.
Of course, as open source co-founder Eric S Raymond pointed out in Linus’ law: “With enough eyeballs, all insects are superficial.” But it requires some bug-spotting eyeballs in the first place to make it work. As Jim Zemlin, Executive Director of the Linux Foundation (LF), said following the Heartbleed and Shellshock security fiascos: “In these cases, the eyeballs weren’t really looking.”
Guess what? Things haven’t changed that much. And, thanks to our increasingly complicated and automated software supply chain, when we miss a bug today, the pain it can cause is that much greater. With our modern continuous integration/continuous deployment (CI/CD) production pipelines, a problem in a small library today can be deployed into thousands of programs tomorrow.
I am not exaggerating. Programmer Marak Squires deliberately added an endless loop into his colors.js package and it was bundled with nearly 19,000 other npm packages and was downloaded 23 million times per week.
Now we are progressing. The LF, OpenSSF, SPDX and OpenChain have all worked on securing the software supply chain with Software BOMs (SBOM), and a standard for them: ISO 5962. If we want to prevent waste from entering our CI/CD pipelines, we have no choice but to adopt SBOMs.
The LF and his friends are also working to spot “new, as yet unknown vulnerabilities in open source code” in the Alpha-Omega Project. Once found, these will be fixed.
It’s all great. But, even though Microsoft and Google have contributed an initial investment of $5 million to the Alpha-Omega project, it is not enough.
If there’s one thing I’ve learned about programmers in my years in tech, it’s this: we’re terrible at security. We are not taught in schools. Most of us put security on the backburner with documentation. To add insult to injury, it’s rarely a priority in our jobs, whether it’s a love project we’re working on in our apartment or our company’s Big Freaking Project of 2022. .
Let’s face it, does the project manager want it done on time or does he want it to be secure? Yeah, you know what Mahogany Row is gonna say.
We need to invest in securing our programs and stop paying lip service to security. This means making safety a real priority in our projects. It means learning to be safe. And that means paying open source developers and maintainers to secure their projects.
There is now an urban legend that open source developers don’t get paid. Please. We came out of the basement a long, long time ago.
As noted open source leader and AWS Vice President Matthew Wilson recently tweeted, Apache Software Foundation (ASF) “Volunteers are often paid very well for their work by companies that set way to include the creation and maintenance of software hosted at the ASF. ‘Volunteer’!= ‘Unpaid.'”
I don’t know everyone in Linux and open source circles, but I know quite a few. Almost all of them are very well paid.
It is true that some important, even vital, projects slip through the cracks. But, the LF looked into the remuneration of these developers. For example, David A Wheeler, director of open source supply chain security for the LF, said that the LF and its related foundations and projects are directly funding people to do security work and the LF is spending more money than ever on security. Here’s how it works.
When a problem is detected, a developer contacts the appropriate LF organization. A contract that briefly describes what problem needs to be solved and how it will be done, the necessary funds for it and who will do the work is put in place. The proposal is then reviewed by the appropriate FL technical contact point.
But – and this is an important “but” – we still don’t pay enough for security. Whether you’re a distinguished engineer closing in on a seven-figure salary or a noob programmer still wet behind your ears, unless the word “security” is in your title, you’re probably not writing secure code. Quick code, yes. Good code, you bet! Security code? Not really.
So when Jack Aboutboul, vice president of product at the software chain security company, CodeNotary recently asked “Have you heard of the Fortune 500 company that emailed an open source maintainer to “Ask for Answers” about its software package?” He makes a valid point.
Businesses are demanding the security of our open source code in new ways. Part of what we need to do going forward is continue educating people about what open source really is.
There are far too many people and companies that assume that open source software comes with some sort of support contract and service level agreement. Spoiler alert: it doesn’t. Never. Never will. If that’s what they want, we have to tell them that you can get it, but you’ll have to pay for it from an open source company. For example, if you want warranties with your Linux, you need to talk to Canonical, Red Hat, or SUSE.
Another part of this is that since people expect more security from our code, we need to think about both teaching developers and maintainers about security and paying them for their security work.
I have known many open source programmers, and they are often very good coders with brilliant minds, but what they are not are security experts. They need help, education, and encouragement to help them fundamentally improve open source security.
It won’t happen overnight. It won’t happen next year. But we’re well on our way to making these kinds of fundamental safety improvements. We just have to buckle up and pay the necessary money to make it happen as soon as possible. ®