Open source software is used by lots of businesses and developers. Whether creating new applications, or keeping a company running smoothly, OSS plays an integral role in our everyday lives. Lauded as a tech utopia for its transparency, accessibility and lack of regulation, the things that have made it so attractive are also a source of risks which we should be aware of, and know how to defend against.
Public code = public vulnerabilities
Anyone can find vulnerabilities in OSS code. Contributors often make bugs public, as well as organisations like the Open Web Application Security Project (OWASP) and the National Vulnerability Database (NVD). However, that doesn’t necessarily mean somebody will immediately produce a patch. Even if somebody does, it can be slow, and meanwhile the vulnerability can be exploited by anyone with far less altruistic intentions, such as cyber criminals.
Lack of security, lack of warranty, lack of obligation = lack of protection
The open and collaborative nature of OSS means that it comes without any legal obligations as far as security, or other aspects of the software go. Anyone can adjust or add code, and the people doing so are often not experts in cyber security. So, even if flaws are identified, for example through OWASP, there may not be an easy fix. Likewise, a lot of OSS has no warranty. And, even if they do, by nature their support team is run by volunteers rather than paid staff members, meaning service can be patchy. As with the lack of security obligation, there are no guarantees that any advice will be correct, and no responsibility taken if it turns out not to be. All OSS software is utilised completely at the user’s risk.
Who’s responsible?
When using open source components, there is a lot to keep track of. Are they really original? If not, there may be copyright issues. Where did the code originate, and can it be traced? How do they interact with other components in the project? Only the developers can take responsibility for this, but this is complex and laborious.
How can I protect myself?
As we all know, prevention is better than cure. Using proper tools to evaluate OSS code before integrating it into your enterprise software can mitigate risk, assess function, and enable patches to be developed. That’s why anyone using OSS code to create new applications or relying on it for their business, should consider using professional help to assess the security of their solutions.
As mentioned in our previous blog post, a SBOM (Software Bill of Materials) should be an essential part of everyone’s DevOps. Like the ingredients on a packet of food or the list of construction materials a builder provides you, a SBOM is a comprehensive list of all the bits of code which make up your project. By identifying all the software used and the associated vulnerabilities, you can protect yourself against supply chain attacks such as Solarwinds, maintainers intentionally adding malware like node-ipc, and severe vulnerabilities like Log4Shell.
Protect yourself today. Click here for your free Agnostic Open-Sourced assessment, which will provide you with an objective and unbiased view of your software landscape.