Nowadays, it is rare to find a business which does not use open source software. OpenUK’s 2022 “State of Open” report found that although 89% of businesses were relying on OSS, many of them had no idea of its details, despite this software being essential for the running of the business.
A responsible business should take a detailed interest in its software supply chain, creating a software bill of materials (SBOM) for each application. This information is crucial so that when security flaws are identified in their software, they can immediately be patched.
Reliance on volunteers
It is well-known that one of the weak points in OSS is that many of the developers who contribute code are volunteers. The widely publicised Log4Shell security incident is a painful case in point. As information about the vulnerability was widespread, a quick fix was expected but did not arrive. The reason? The maintainers of the project were volunteers with day jobs, who were not on call for urgent security fixes. This vulnerability alone is estimated to have affected 93% of enterprise cloud environments.
Neglecting any software dependency is risky, but when it’s open source and widely used, it becomes especially dangerous. We are in a situation where major companies are completely dependent on software which is maintained by unpaid people, who keep it secure through goodwill, rather than because they are obliged to do so.
Why you should be using an SBOM
Many businesses have critical dependencies but don’t take action to support either the maintainers or the projects. If you have an SBOM, it means that detailed information about the software you are using is readily available. Organisations supplying software to others are now increasingly expected to provide an SBOM alongside the code.
Know your dependencies, know your risks
Knowing your dependencies makes it easier to assess the risk associated with each one. Have issues been responded to, and have there been any releases recently? Being able to see the maintainers and activity for each project helps us to understand the project’s health.
Businesses can help reduce risks by supporting the projects which they depend upon. Open source projects live and breath through contributions. Open source means shared ownership, and shared responsibility. By all doing our bit, we can simultaneously reduce our workload, while increasing quality.
Risk reduction best practices for businesses
- Use some of your own engineering resources to contribute to bug fixes or features to projects
- Keep your own engineers involved in a project, so they get to know it and can keep an eye on new features, or when a new release is available
- Create an OSPO (open source program office), with staff dedicated to contributing to or maintaining the projects used by the organisation
- Support organisations that exist to support open source, such as OpenSSF (Open Source Security Foundation) and Tidelift
Securing a safer software future
Widely used by businesses, OSS is also secure, as long as the organisation has clear knowledge of the software supply chain and its dependencies. When a problem does arise, having the details of your software to hand helps significantly reduce the risk of events like Log4Shell incident occurring in the future.
Open Source Review
Gain visibility across your software supply chains. Knowing your current position in relation to Open Source exposure will help you plan a path forward for software lifecycle success.
We provide a simple three step process to help you manage your Open Source Software supply chain.
Start with an assessment to learn your starting point and plot a path to success.