Software is at the heart of all modern businesses and is critical in all aspects of operations. Almost every company will use open source software, knowingly or otherwise, as even proprietary software depends on open source libraries. OpenUK’s 2022 “State of Open” report found that 89% of businesses relied on open source software, but not all are clear about the details of the software they rely on.
Companies are increasingly demanding more information about their mission-critical software. Responsible companies take a detailed interest in their software supply chain and create a software bill of materials (SBOM) for each application. This level of information is critical so that when security flaws are identified in their software, they can immediately be sure what software and versions are in use and what systems are affected. Knowledge is power in these situations!
Dependence 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 though 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 were a closed source component, the vulnerability might never have been made public, leaving organizations open to attack. The open source nature of the library meant that it could be inspected, problems found and advised by others. So yes, the maintainers were not called for security issues in their volunteer project. The big question then is: How did we get into a situation where large companies depended on software that was the responsibility of someone doing something else to pay their bills?
Neglecting software dependencies is a risky business regardless of the license of the software, but when it’s open source and widely used, it becomes especially dangerous. Sticking to the story of one vulnerability; the problem had existed in the codebase for years but was not discovered. The tool that was so widely used was actually not that widely supported – and what happened next is history.
This story is repeated over and over, across so many companies that have critical dependencies but do nothing to support either the maintainers or the projects themselves. Having a SBOM for the software used by a company means they have the information at their fingertips. For organizations that deliver software to others, the expectation to deliver SBOM along with the code is increasingly the norm.
Know dependencies to assess risk
Bringing knowledge about the dependencies makes it easier to assess the risk associated with each one. These open source projects are the easiest to assess: are issues being addressed and have there been any recent releases? Being able to see maintainers and project activity for each project provides good insight into the health of the project.
Companies can play their part to reduce risks by supporting the projects they depend on. Some projects accept sponsorships directly through the GitHub sponsorship scheme, others may instead appreciate offers of hosting or a security audit. Any open source project values contributions. If your company had created this library themselves, the engineers in the company would have to fix every single bug themselves.
Open source is more like a shared ownership arrangement. We don’t all have to build the same thing over and over, but rather can contribute, which is both less effort and leads to better quality as a result. One of the most impactful things companies can do is to use some of their technical resources and contribute bug fixes or features to projects that are so core to the business.
Keeping your own engineers involved in a project has many advantages. They get to know it and can keep an eye out for new features or when a new release is available. It is critical that 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 dependency problem. A number of organizations, including Aiven, have an OSPO (open source program office), with staff dedicated to contributing to or even maintaining the projects that the organization uses. These departments often contribute to the company’s overall presence 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. OpenSSF (Open Source Security Foundation) works to improve the security of open source projects and is funded by the organizations that depend on these projects. It also publishes excellent learning resources so companies can educate themselves about the risks of the software they use. Another similar organization is Tidelift, which works with maintainers to ensure that certain basic requirements are met, again funded by the organizations. Tidelift also provides tools and training to help companies manage their software supply chain and adopt best practices in this area.
Ensuring a safer software future
Businesses rely 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 occurs, it helps any organization depend on healthy projects and having the details of your software available. If every organization did this, the risk of incidents like the Log4Shell vulnerability would be reduced.