Mirko Zorz, Director of Content, Help Net Security

June 18, 2024

Enhancing security through collaboration with the open-source community

In this Help Net Security interview, Alan DeKok, CEO at NetworkRADIUS, discusses the need for due diligence in selecting and maintaining open-source tools, and brings out the potential risks and benefits of collaborating with the open-source community to enhance software security.

open-source software security

How do vulnerabilities in open-source dependencies impact overall security?

Many companies use open-source software without really examining the projects in detail. The idea seems to be that if the project is public, it must be fine, right? However, as we’ve seen with the Heartbleed attack on OpenSSL, the truth is that no one caught the error, even though anyone can look at the relevant code. Many companies downloaded the code, put it in a product, and used it without doing any due diligence.

In such cases, the lack of diligence impacts overall security, not necessarily the decision to choose open-source.

Un-vetted open-source tools can certainly reduce system security. There are hundreds of companies selling cheap products (network devices, desktop software, etc.) which depend on open-source. Most of those products are likely to have security issues. The reason those issues haven’t been found is because no one is looking.

How does the security of open-source software compare to that of proprietary software, particularly in high-stakes environments?

Most closed-source software is used internally in corporations, where it’s not publicly accessible. Therefore, security issues are less important. History shows that when closed-source software is used on the public internet, it has similar security issues to what we see with open-source software.

In high stakes environments, vendors often audit the software they use (proprietary or not). But this isn’t always the case, as seen with the recent VPN issues with CISCO ASA devices. Nation-state attackers were able to test and develop a way to break into the private networks of governments a year ahead of when they were caught, with potentially disastrous consequences.

Just because it’s proprietary doesn’t necessarily mean it’s safer by default. The quality and security posture of open-source products varies greatly. If organizations choose wisely, there shouldn’t be any additional risk in selecting an open-source tool.

What are some best practices for maintaining a secure open-source environment within an organization?

The first step is to use open-source projects that many other people are using. They’re more likely to be secure than projects which are used by only a small number of people.

The second step is to verify that the project maintainers take security seriously. Do they have good processes? Do they sign commits? Do they run source code scanners? Do they respond quickly and diligently to security issues?

Another effective strategy is to track a modern, stable OS (Ubuntu, RedHat, FreeBSD, etc).

Finally, you want to ensure someone in your organization is responsible for keeping all systems up to date with the latest set of patches.

How do compliance and regulatory requirements influence the selection and use of open-source software?

Without funding, it is difficult for open-source projects to get official certifications. So, companies in regulated sectors that need those certifications often can’t use open-source solutions.

For the rest, open-source really has “eaten the world.” Most modern tech companies wouldn’t exist without open-source tools, or would have drastically different offerings. For these companies, they must take on the cost of doing compliance checks for the open-source software that they use.

If all those companies worked together to contribute back to the original open-source project, they would generally all be better off. But, in our experience, once organizations fall into the commercial mindset of “it’s mine, you have to pay for it,” it’s difficult for them to embrace why it’s useful to contribute back to the community.

How can CISOs effectively assess and manage the risks of integrating open-source components into their infrastructure?

The main risks are legal/license compliance, along with security risks from using (or abusing) external software components. CISOs need to ensure that the product teams track which open-source projects are being used, and that those projects are up to date.

A related issue which isn’t often talked about is the risk of “forking” the open-source project, which means someone creates a copy of the original project’s source code and further develops it independently. The usual mindset for forking is “we have the source, so we can change it!” But after a few years of custom changes, you’re now running a custom fork of the original project, with different bugs and different features. It’s then almost impossible to take advantage of newer releases of the open-source project. The forked project has, in a sense, become its own distinct software – making upgrades difficult.

We’ve seen this with FreeRADIUS many times. We’ve always recommended that our customers use a “clean” version of FreeRADIUS, with little to no changes. That way, it’s trivial for them to upgrade, fix issues, add features, etc. This process has saved our customers substantial amounts of time and effort over the years, and it’s one I think anyone who adopts open-source should follow.

How can organizations effectively collaborate with the open-source community to enhance the security of their software?

I feel strongly that organizations *should* collaborate with the open-source community. Too many just download the open-source project and run away. One way for corporate entities to get involved is by contributing bug fixes and small features. This can be done through anonymous email accounts if it’s necessary to keep the company’s involvement private.

Companies should also use the results of their security analysis to help improve the original project. There is some self-interest involved here. Why should a company use its resources to maintain proprietary patches for an open-source project when it can instead send those patches back and have the community maintain them for free?

Google has been doing a good job of this with their OSS-FUZZ project. It has found many bugs and helped a large number of the open-source projects using it.

Coverity is also a great example, as they’ve been helping open-source projects with static analysis. FreeRADIUS was one of the first open-source projects to be scanned with Coverity, and they’ve been extremely helpful in identifying bugs.

I’ve spent the last 15 years working with companies to help them use open-source, contribute to open-source projects, and make the internet better. I think all involved have benefited from this collaboration, which shows the power of the open-source community working in conjunction with companies that use their products.

Must read:

More about