Neglecting Open Source Developers Puts the Internet at Risk

Software is at the core of all modern businesses and is crucial in every aspect of operations. Almost every business will use open source software, knowingly or otherwise, since even proprietary software depends on open source libraries. OpenUK’s 2022 “State of Open” report found that 89% of businesses were relying on open source software, but not all of them are clear on the details of the software they rely on.

Businesses are increasingly demanding more information about their operation-critical software. Responsible businesses are taking a detailed interest in their software supply chain and creating a software bill of materials (SBOM) for each application. This level of information is crucial so that when security flaws are identified in their software, they can immediately be certain which software and versions are in use, and which systems are affected. Knowledge is power in these situations!

Reliance on Volunteers

In late 2021, a security vulnerability called Log4Shell was identified in a widely used Java logging framework, Log4j. Since this is a widely used, open source library, the vulnerability was well-publicized, and fixes were expected. However, the maintainers of the project were volunteers. They had day jobs and were not on call for urgent security fixes, even if a large number of systems were affected. This vulnerability alone was estimated to have affected 93% of enterprise cloud environments.

At the time, there was some negative press about open source, but the truth is that if this was a closed-source component, the vulnerability may never have been publicly known, leaving organizations open to attack. The open source nature of the library meant that it could be inspected, the problems found, and advice offered by others. So, yes, the maintainers weren’t on call for security problems in their volunteer project. The big question, then, is: How did we get into a situation where major companies were depending on software that was the responsibility of someone who does something else to pay their bills?

Neglect of software dependencies is a risky business whatever the license of the software, but when it’s open source and very widely used, it becomes especially dangerous. Sticking with the story of one vulnerability; the problem had existed in the codebase for years, but wasn’t spotted. The tool that was so widely used was not, in fact, so widely supported — and what happened next is history.

This story is repeated over and over, across so many businesses that have critical dependencies but don’t take action to support either the maintainers or the projects themselves. Having an SBOM for the software used by a business means they have the information on hand. For organizations that supply software to others, the expectation of supplying the SBOM alongside the code is increasingly the norm.

Know Dependencies to Assess Risk

Bringing knowledge of the dependencies makes it easier to assess the risk associated with each one. These open source projects are the simplest to assess: are issues responded to, and have there been any releases recently? Being able to see the maintainers and project activity for each project gives good insight into the project’s health.

Businesses can play their part to reduce the risks by supporting the projects upon which they depend. Some projects accept sponsorship directly via the GitHub Sponsors scheme, others might instead appreciate offers of hosting, or a security audit. Every open source project appreciates contributions. If your business had created this library itself, then the engineers inside the company would have to fix every bug themselves.

Open source is more like a shared ownership scheme. We don’t all have to build the same thing repeatedly, but rather can contribute, which is both less effort and leads to better quality as a result. One of the most impactful things businesses can do is use a little of their engineering resources and contribute to bug fixes or features to projects that are so core to the business.

Keeping your own engineers involved in a project has many benefits. They get to know it and can keep an eye on new features, or when a new release is available. Crucially, the business has insight into the health and status of the dependent project and is part of what keeps it healthy, reducing the risk to the business of a problem with a dependency. A number of organizations, including Aiven, have an OSPO (open source program office), with staff dedicated to contributing to or even maintaining the projects used by the organization. These departments often contribute to the general presence of the company in the open source ecosystem and enable other employees to engage with open source.

Another approach is to support the organizations that exist to support open source. The OpenSSF (Open Source Security Foundation) works to improve the security of open source projects and is funded by the organizations that depend on those projects. It also publishes excellent learning resources so that businesses can educate themselves about the risks of the software they use. Another similar organization is Tidelift, which partners with maintainers to ensure certain basic requirements are met, again funded by the organizations. Tidelift also provides tooling and education to help businesses manage their software supply chain and adopt best practices in this area.

Securing a Safer Software Future

Businesses depend on software, and this includes open source software, which is widely used and typically more secure than proprietary alternatives.

This is a smart move, but an even smarter move is to have clear knowledge of the software supply chain and its dependencies. When a problem does arise, depending on healthy projects and having the details of your software available helps every organization. If every organization did this, then the risk of having events such as the Log4Shell vulnerability are reduced.