Open source software: Ways for CISOs to quell the fear

For many stakeholders, there is plenty to love about open source software. Developers tend to enjoy the ability to speed application development by borrowing open source code. CFOs like the fact that open source is often free or low in cost. IT teams benefit from the sprawling, dynamic support communities that surround major open source projects.

Yet, for CISOs, open source is more likely in many cases to inspire fear than love. Open source libraries and modules have been at the heart of many of the major software supply chain security vulnerabilities in recent years – which is not surprising given that, on the whole, open source projects lack the extensive security oversight that major commercial software vendors provide.

But there’s good news: When organizations leverage open source in a deliberate, responsible way, they can take full advantage of the benefits that open source offers while minimizing the security risks. To that end, this article offers guidance on achieving a best-of-all-possible-worlds approach to incorporating open source into enterprise software supply chains, focusing especially on emerging open source security practices that extend beyond conventional measures for validating open source software components.

The age-old question: How secure is open source software?

Let’s begin by discussing a fundamental issue: whether open source software is actually any less (or more) secure than closed-source code.

Since the 1990s, when open source platforms like Linux and the Apache Web Server first made their way into enterprise production environments, debate has raged about whether open source software is as secure as closed-source alternatives.

Generally speaking, viewpoints on this topic can be distilled into two major perspectives:

• The argument made by open source advocates, who typically contend that open source is more secure because anyone can inspect it and discover security vulnerabilities
• The argument made by closed-source software vendors, who tend to make the case that closed-source code is more trustworthy because it is subject to more careful security oversight and controls than open source software, which in many cases is developed by volunteers

Both arguments have their merits – and their flaws. For instance, while it’s true that open source software may be more secure because anyone can theoretically check it for security flaws, this doesn’t mean that there are thousands of volunteers constantly poring over open source repositories, looking for security risks. Just because everyone can help to make open source more secure doesn’t mean everyone actually does.

If they did, the world might have avoided security fiascos like the Log4j and regreSSHion affairs, both of which stemmed from vulnerabilities in widely used open source code. In addition, security might be among the top reasons why companies choose not to use open source, according to an IDC report on open source adoption in the enterprise (Open Source Software Trends, September 2023). And the same report might not have found that open source code is more likely than closed-source software to be linked to security incidents. See figure below.

At the same time, although many closed-source software vendors do invest heavily in security, their track record is far from perfect. Indeed, some of the most serious breaches of recent years, like the SolarWinds and Kaseya attacks, resulted from security flaws in closed-source code bases maintained by companies that, by all appearances, take security very seriously – yet were breached nonetheless.

In short, it seems impossible to prove that open source is any more or less secure than closed-source code. What it is clear is that both types of software can, and do, expose organizations that depend on them to major attacks.

New approaches to managing open source security risks

For CISOs whose companies deploy open source code – as nearly four-fifths of enterprises do today, according to the IDC report mentioned above  – the real question to answer is not how secure open source is, but what they are doing to ensure that they mitigate the security risks associated with open source code.

In the past, strategies for managing open source risks tended to boil down to relatively simplistic practices, like scanning open source code for security vulnerabilities prior to deploying it or incorporating it into an enterprise code base.

Those practices remain important today. However, CISOs are now taking additional steps to use open source responsibility. One key emerging practice is increased adoption of software supply chain security tools, which help to automate the process of identifying and validating the source of third-party components in software supply chains – including those that originate from open source products.

Although this type of solution is currently in use within only a minority of enterprises, the IDC report cited above concludes that software supply chain security tools are likely to play an increasingly important role in the ability of enterprises to leverage open source in a secure way – especially if tool vendors can improve their solutions so that they better meet the needs of enterprises that rely heavily on open source. See figure below.

IDC U.S. Open Source Software Use Survey, August 2023; base = respondents indicated organization experienced impact; n = 91 (all software), 131 (OSS)

Other practices for mitigating open source security risks include setting criteria for when and from where enterprise developers may borrow open source code. From a security perspective, there is a huge difference between large, highly active open source projects, like Linux or Kubernetes, and obscure open source repositories on sites like GitHub. The latter are less likely to offer strong security protections or to respond quickly in the event that someone discovers vulnerabilities within their code base.

To be as effective as possible, criteria surrounding which types of open source projects developers can use should be clear and consistent. For instance, rather than simply establishing a governance policy requiring coders to use good judgment when deciding whether to borrow a repository’s code, an enterprise might consider generating an approved list of open source projects or software components that developers may draw from, as well as implementing an approval process for adding new software sources to the list.

Conclusion: The bright – but complex – future of open source software security

Given the depth and breadth of the adoption of open source software in the modern enterprise, it seems unlikely that security concerns will stop businesses from depending on open source code anytime soon. That said, data does show that open source is somewhat more likely to be linked to attacks than closed-source software, suggesting that CISOs should do more to get ahead of open source security challenges. On their own, basic practices, like scanning open source code, don’t suffice. Enterprises must adopt additional measures, like those described above, if they truly wish to maximize the benefits they glean from open source while minimizing the security challenges they face.