Peace, not war: In principle, many people can rally behind this motto. However, the means used by U.S. developer Brandon Miller to spread this message in March 2022, after the start of the war in Ukraine, were met with a lack of understanding. He hid sabotage code in the OSS software module he manages and uses worldwide called node-ipc, which deleted files on computers with Russian and Belarusian IP addresses and replaced them with heart emojis. The name of the update version of the software module, which was downloadable for about 24 hours, was peacenotwar. The hack was reported by news magazine Der Spiegel and IT trade magazine Heise, among others. "Unfortunately, this incident has cost a lot of trust in open source software," says CISPA researcher Dominik Wermke.
Open source software (OSS) is software whose source code is visible publicly, the researcher explains. In most cases, it can also be copied, used, and modified as desired. "Services like GitHub and GitLab, however, have long made open source a social phenomenon as well." GitHub and GitLab are platforms where OS software projects in development can be managed. "In some cases, small hobby projects are located there, on which only a few developers are working; in other cases, several hundred or even thousands of people are collaborating on projects," says Wermke. In this way, independently usable and often free programs are created. Sometimes, however, only parts of the open source code are used and embedded by other projects or companies in their programs. "Often, however, large companies consciously decide to make the source code of parts of their programs public and hope that so many developers will work on them and uncover errors."
Meanwhile, OSS makes up a large part of the Internet's infrastructure. The web browsers Mozilla Firefox and Google Chromium - the little sister of Google Chrome - and the Android operating system, for example, are based on it. A good reason to take a closer look at how OSS projects are organized. "We originally wanted to look directly at the security of OSS projects and establish criteria to measure it. But we quickly realized that there was not yet a sufficient database for this." A qualitative study in which Wermke and colleagues interviewed a total of 27 contributors to OSS projects, from project founders to maintainers and code contributors, now provides them with good evidence for further research.
"We wanted to talk to project participants to find out exactly how projects are structured, whether there are guides and guidelines for developers, and how projects deal with security and trust issues." The answers varied widely depending on the type and size of projects stakeholders are working on. "The larger the scope of the projects and the greater the number of contributors, the greater their need for security and trust processes. Smaller projects don't seem to address security and trust incidents until they occur." Who is allowed to contribute code and how closely new contributions are vetted before they flow into OSS projects also varied. Most respondents said they are aware of the danger posed by suspicious or low-quality code contributions. In some projects, entire security teams are dedicated to incident and code contribution review. In others, mainly smaller and younger projects, at least one contact person is usually designated to deal with security issues.
However, the study also shows that it is elementary for the projects to keep the hurdles to participation as low as possible. In addition, there is often a lack of staffing and financial resources to develop guidelines and manuals or to introduce complicated review processes. Wermke says, "We advocate supporting open source projects in a way that better takes into account their individual strengths and limitations, especially in the case of smaller projects with a small number of contributors and limited access to resources." What exactly that support might look like requires further research. Wermke has already identified one topic that could soon appear on his research agenda: "It would be exciting to look at how small projects deal with suspicious code contributions. They often lack the staff and time to screen such code thoroughly. Maybe there are ways to help them with guidelines or checklists."
It's too early to say how safe OSS is, and it can probably never be answered in such a blanket way for the entire field because of the diversity of projects. "But hopefully, we can help introduce new and helpful security standards with our research."
translated by Oliver Schedler
