Software is at the heart of all modern businesses and is central to every aspect of operations. Nearly every company will use open source software, knowingly or not, as even proprietary software depends on open source libraries. by OpenUK The 2022 “State of Open” report found that 89% of companies relied on open source software, but not all are clear on the details of the software they rely on.
Businesses increasingly require information about their critical operating software. Responsible companies are taking a detailed look at their software supply chain and creating a software bill of materials (SBOM) for each application. This level of information is critical so that when security holes are identified in their software, they can be instantly certain what 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 has been identified in a widely used Java logging framework, Log4j. As this is a widely used open source library, the vulnerability was well publicized and fixes were expected. in any case, the the project maintainers were volunteers. They had day jobs and weren’t available for urgent security fixes, even though a large number of systems were affected. This vulnerability alone is estimated to have affected 93% of enterprise cloud environments.
At the time, there was negative press about open source, but the truth is that if it was a closed-source component, the vulnerability may never have been made public, leaving organizations open to attack. The open source nature of the library meant it could be inspected, problems found, and advice offered by others. So, yes, the maintainers were unavailable due to security issues in their volunteer project. The big question, then, is how did we get to a situation where big companies depended on software that was the responsibility of someone doing something else to pay their bills?
Neglecting software dependencies is risky business whatever the software license, but when it’s open source and widely used, it becomes especially dangerous. Staying true to the story of a vulnerability; the problem existed in the code for years, but it hasn’t been pinpointed. The tool so widely used was, in fact, not so widely supported – e what happened next is history.
This story repeats itself over and over, in so many companies that have critical dependencies but take no action to support either the maintainers or the projects themselves. Having an SBOM for the software used by a company means having the information at your fingertips. For organizations that ship software to others, the expectation to ship the SBOM with the code is increasingly the norm.
Understand dependencies to assess risk
Bringing knowledge about addictions makes it easier to assess the risk associated with each one. These open source projects are the easiest to evaluate – are there any bug fixes and have there been any recent releases? Being able to see the maintainers and project activity for each project gives you a good insight into the health of the project.
Businesses can do their part to reduce risk by supporting the projects they depend on. Some projects accept sponsorship directly through the GitHub Sponsors scheme, while others may appreciate hosting offers or a security check. Every open source project appreciates contributions. If your company built this library by itself, the engineers within the company would have had to fix every bug by themselves.
Open source is more like a shared ownership scheme. We don’t all have to build the same thing over and over, but rather we can contribute, which involves both less effort and, consequently, better quality. One of the most impactful things companies can do is use some of their engineering resources and contribute bug or feature fixes to projects which are so fundamental to the business.
Keep your engineers involved in a project it has many advantages. They know about it and can keep an eye out for new features or when a new version is available. Basically, the company has great insight into the health and status of the employee project and is part of what keeps it healthy, reducing the company’s risk of an issue with an addiction. A number of organizations, including Aiven, have an OSPO (open source programs office), with staff dedicated to contributing to or even maintaining the projects used by the organization. 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 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 organizations that depend on those projects. It also publishes excellent learning resources so companies can educate themselves on the risks of the software they use. Another similar organization is Tidelift, which works with maintainers to ensure 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 more secure software future
Businesses depend on software, and that 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 a clear understanding of the software supply chain and its dependencies. When a problem occurs, depending on healthy projects and having the details of your software available helps every organization. If every organization did this, the risk of having events like the Log4Shell vulnerability would be reduced.