Is open source safe?

Tim Mackey, the principal security strategist at the Synopsys Cybersecurity Research Centre, answers a question troubling many IT specialists: is open source safe?

As new vulnerabilities are disclosed against open source components and new attacks are launched against repositories of open source components, and even against open source development methodologies, it’s important to ask the question: just how safe are open source components?

In order to answer this question, we must first define some parameters. This is crucial since open source technologies power modern software development. In fact, there are very few software applications and services that don’t have at least some open source elements in them.

Open source components range from the foundational, such as services that keep the clocks of servers, mobile phones and computers in sync or encryption libraries used to secure internet traffic, through various software development kits enabling rapid innovation in IoT ending with simple utilities designed to make automation of common tasks like software deployment easier. All of these millions of open source projects have one thing in common – the source code is freely downloadable and anyone can create a derivative of the main project without approval from the project owners.

It is this freedom that powers innovation and represents risk. After all, if anyone can create a derivative of a project, then that must mean that attackers can spoof any project at any time. The end point of that argument is open source must be “unsafe,” deficient or insecure in some way.

The counterpoint being that commercial software is somehow safer due to tighter controls or greater resources. What those making this argument don’t realize is that commercial software is on average 70% open source, but more importantly, all software has bugs and no software development process is perfect.

Furthering this point, of the 1,500+ codebases scanned in the 2021 Open Source Security & Risk Analysis (OSSRA) report, 98% contained open source. Additionally, of those scanned, 84% of codebases contained at least one vulnerability—an 9% increase from the previous years’ findings.

Since all software has bugs, bugs can be exploited and even the most secure software can be deployed in an insecure manner. So why does the safety and security of open source keep coming up? Well, if open source components are good enough for commercial software vendors to use, that must mean something? And, if open source technologies are good enough for the largest cloud providers, that must mean something too, right? What do they know that those asking safety and security questions don’t?

It turns out that the core problem is one of familiarity and, well, blame. There is no vendor known as “open source.” This means in part that when someone wants to procure an open source solution, there is no contract to sign and by extension nothing for corporate procurement teams to do. Since corporate procurement teams are often the gatekeepers for compliance within business, this then implies that anyone can bypass compliance, and that’s a bad thing. Just imagine the chaos if everyone could freely download the software they required without IT or procurement being involved.

While that last sentence reads as tongue-in-cheek, the reality is that any software that enters an organization without IT involvement isn’t likely to be patched. And patch management in open source is very different than with commercial software. With no single origin point for an open source component, it’s important to keep track of where each component or application was downloaded from. That’s where any patches or updates need to come from.

Since we all know how important patching is for security, if there are any unpatched open source components in your business, then that’s a risk, particularly given the reality that open source software is freely downloadable without IT involvement.

Once you know the origin of the open source component, not only can you create a patch strategy for it (hint: updates work differently than with commercial software), but you can also assess the safety of the component. Component safety in this context refers to how the component is actually developed.

Common questions to ask at this point include:

• Am I at a true origin or on a fork? True origins represent the main development effort for the component, and a fork is any branch of the component. Unless you have a really good reason to use a fork, you should always be using the true origin of the component, also known as “upstream.”

• Does the component have a well-defined security policy? Only the most popular open source projects have such a policy, and the policy will describe how security incidents are managed.

• Is there a well-defined contribution model? Open source projects thrive when there are active contributors, but if there isn’t a defined contribution model, there likely isn’t a set of criteria for what a high-quality contribution looks like. Some contribution guidelines explicitly set testing requirements for any contribution.

• Who are the top contributors? All software has contributors, but not every contributor understands the entire source code. If the top contributors are new to the project, that could indicate a shift in development priorities or that long time contributors have moved away from the project.

While there is no real difference in the safety of open source versus commercial software, the reality is that there are multiple safety standards within different industries and all software, regardless of origin, will need to be vetted against applicable standards.

READ MORE:

• The world’s first bot management open-source framework unveiled today
• EA falls victim to source code theft
• The low code conundrum and its impact on business operations
• How to make low-code platforms more effective for the enterprise

For usage where safety standards don’t exist, the question of safety is really one of management. Are your teams able to guarantee that they can patch open source components and are vetting the changes in any updates? If you don’t have a good open source management process in place, the safety of individual components shouldn’t be a top priority.

For more news from Top Business Tech, don’t forget to subscribe to our daily bulletin!

Follow us on LinkedIn and Twitter