Over the past few months, the open-source community has seen several critical events that have led to big questions about the security and safety of open-source software. How can we evaluate what is currently taking place around open-source projects and security, how can we make these projects more sustainable, and what should we do in the future?
Security Matters
From the start, we should acknowledge two things. The first is that software is written by people, and people make mistakes. This means that there will always be issues in software that have to be fixed. The second is that open-source software is now more widely used than ever before. When issues are discovered, they will affect more organizations.
A recent example of this is Apache Log4j, an open-source logging tool that is built into a huge range of software projects. The security issue was discovered initially in Minecraft, before the scale of the issue was understood and patches rushed out to fix the project. The problem impacted tens of thousands of organizations worldwide. Thankfully – according to research by Sophos – the fault itself has not been as widely exploited as was feared. This was due to the prompt work that the open-source community took to fix the problem, and how fast organizations were able to deploy updates.
A few weeks later, two widely used Javascript libraries (colors.js and faker.js) were sabotaged by the maintainer responsible for them, leading to broken applications where those libraries were installed. He claimed he was tired of other companies profiting from his work. This incident affected tens of thousands of websites and applications worldwide. The libraries were quickly rolled back to versions that did not have the issues included.
Researchers at the University of Minnesota also tried to prove that there were issues around security in open source by submitting Linux kernel patches with malicious code included, to see if they would make it through the various review processes in place. In this instance, the issues were quickly caught and they did not make it through to being included. The university’s research team was also roundly criticized for their approach to this in the first place, as their methodology was flawed.
What all these issues point to is a problem around security that open source has had to fight against for the last 20 years. The argument has been that, because open-source projects are not owned and maintained by a single commercial entity, strange and malicious things can easily make it into the source code.
What Does the Future Hold for Open Source and Security?
To counter this, open-source projects will point to the fact that being open makes it easier to spot potential problems and fix them. In theory, open-source code can be examined and verified by anyone, either the organizations themselves or by either yourself or third parties that are trusted to carry out that work and verify its security for you. Closed-source programs don’t have that same approach, so you need to take it on faith that the code is clean of problems.
In practice, this “many eyes” model works when there are the resources available to carry out the work. It is correct to define this as work – it needs experience, skill, and time to find those potential problems. They do come to light regularly – for example, Qualys found an issue in January 2022 around Polkit, a tool included in every Linux operating system version, where the issue had existed for more than 12 years. This length of time is not ideal for any software project, so more needs to be done in order to make this work viable for project maintainers and companies that use these tools for their own benefit.
To make this more effective over time, the U.S. government is already meeting with leading figures in the open-source sector to discuss how best to plan ahead around security issues. This includes mandating a software bill of materials (SBOM) for all projects by federal government organizations, which will increase the insight that teams have into any dependencies that their software products have. This will make it easier to understand and fix potential problems in the future. At the same time, these discussions will cover how to make open-source security work more sustainable.
Open source is already trusted and used by millions worldwide. While incidents like the ones above put a spotlight on certain issues or flaws, these same issues exist in non-open-source software and services. The more adoption and users using a particular piece of software, the more impactful an issue will have. Look back the last few years at big security issues or bugs related to software and you will see these pop up in both open-source and closed-source software, such as the attack on Solarwinds.
As a community, we can do better. These incidents give us the opportunity to think about how to make open-source projects safer, more sustainable, and more secure in the long term. First, we need companies that rely on key components to participate and contribute back to the community and that particular project. Next, we need to support the maintainers and creators of critical open source. Open-source projects get better with active participation, and this includes providing support for those maintaining projects directly. Maintaining a successful project needs to be more than just a labor of love.
Having dedicated time and resources to continuously check, secure, and enhance commonly used software is critical. As a community, we need to adopt a stance that makes security around contributions, quality of code, and checking projects easier and clearer over time. The open-source approach makes that easier for everyone in the future, based on a more sustainable approach that covers project maintainers and contributors as well as those that use them.