Should organizations renounce open source software altogether?

Open source software is a data security nightmare. According to Synopsys, while 96% of software programs contain some type of open source software component, 84% of codebases contain at least one vulnerability.

These vulnerabilities are not only present in internal software, but also in third-party applications and services scattered across on-premises and cloud environments.

Awareness of software supply chain threats has grown in recent years, with President Biden releasing an Executive Order in May 2021 calling on federal government agencies to create a software bill of materials (SBOM), to produce a inventory of software components used across all your environments.

Likewise, the revelation that the Log4j vulnerability affected 58% of organizations showed that organizations needed to do more to scrutinize the software they use in their environments.

While the ubiquitous use of open source software means that organizations cannot entirely forego these tools, there are some steps organizations can take to begin mitigating the risk of exposing critical data assets.

What are the risks faced by open source software?

One of the biggest threats facing open source software is supply chain attacks. In a supply chain attack, a cybercriminal or state-sponsored threat actor will target the maintainer of an open source project so that they can embed malicious code into an open source library and send it to any downstream organization that download it.

This style of attack is becoming increasingly common to the point where research suggests there has been an average annual increase of 742% in software supply chain attacks over the last three years, with Sonatype discovering 106,872 malicious packages available online.

“From a supply chain perspective, it is increasingly common to see malicious code introduced into open source – and this can be done by compromising a legitimate project or through a malicious project designed to trick users into downloading counterfeit code that resemble a typical project,” said Dale Gardner, senior principal analyst at Gartner.

Gardner suggests that organizations that rely on open source software need to assess the risk posed by each project.

“For example, the project has a good track record for responding to issues, the appropriate security controls are in place, the code is up to date, and so on. And from a supply chain standpoint, it’s not just open source we should be concerned about – we’ve seen multiple cases where commercial code has been compromised,” said Gardner.

Frameworks such as the Secure Software Development Framework (SSDF) and Supply Chain Tiers for Software Artifacts (SLSA) are a way in which organizations can assess software vendors for potential weaknesses, to assess the risk of software that they use to create their own apps.

Defining Acceptable Risk in the Open Source Supply Chain

Another way to manage risk when implementing open source software is to define acceptable risk. It boils down to deciding whether the vulnerabilities presented by a given application present an acceptable and manageable level of risk.

“Organizations using open source software, which today are all digitized businesses, benefit from developing and socializing an open source strategy. A strategy provides guidelines on when open source can be used, what approval is required and what is an acceptable risk to the business,” said Janet Worthington, senior analyst at Forrester.

“Have a plan in case a high-impact security vulnerability is disclosed. Your development team may have to back-port a fix to the open source library version your organization depends on,” said Worthington.

Worthington points out that organizations can start coding and measuring risk by creating a SBOM and maintaining an inventory of all purchased and downloaded software. In addition, security leaders should also ask vendors to provide a description of their secure software development practices.

When it comes to open source libraries, Worthington suggests organizations should first look to an SBOM; if there isn’t one, scanning with a software composition analysis (SCA) tool can help reveal vulnerabilities in the code. You can see if there are updates or patches available to mitigate it.

However, if you choose to use an SCA to scan open source components, it is important to note that tools that use package managers to identify and scan packages are susceptible to vulnerabilities and missing software packages.

Going beyond SCAs and SBOMs

One of the main challenges of securing open source software components in the enterprise is that they are not static. Third parties can make changes to open source software that, at a minimum, create new vulnerabilities and, at worst, create actively malicious threats.

While Lisa O’Connor, global security research lead at Accenture, notes the importance of static application security testing and SBOMs, she cautions that “we need to go much deeper to understand the risks.”

“Researchers at Accenture’s Security Research and Development Labs are currently working on next-generation SBOM traceability to bring the sophistication needed not only to identify security threats, but also to understand the downstream effects of open source vulnerability functions at the base of an organization’s actual installed code,” said O’Connor.

The organization’s security research and development labs are currently working with Professor David Bader of the New Jersey Institute of Technology (NJIT), an expert in knowledge graphing and analysis, to help improve the way organizations identify and isolate components vulnerable open source.

Understanding risk as the software supply chain evolves and moves is key to mitigating open source risk. Dynamic risks require an equally flexible mitigation strategy.