June 29, 2023 By Sue Poremba 4 min read

Software depends on layers of code, and much of that code comes from open-source libraries. According to an Octoverse 2022 report, open-source code is used in 97% of applications. Not only do developers embrace open source, but so do nine in 10 companies.

“Open-source software is the foundation of 99% of the world’s software,” Martin Woodward, VP of developer relations at GitHub, told VentureBeat.

As the foundation of just about every piece of software, every application or device runs on code that could be accessed by millions of developers. And if there is a vulnerability in any one piece of open-source code, it could lead to a cybersecurity nightmare across the software supply chain. 

The open-source trust factor

Open-source software offers many benefits. It’s cost-effective, saving developers time and money by using readily available code rather than having to build from scratch. But at the same time, it also introduces significant risk to applications and organizations if the code is not properly vetted and managed.

There’s a tendency to treat open-source as monolithic, that all code will have the same levels of integrity and security. The reality is that using open-source is risky business if you aren’t taking the proper steps to ensure reliability and close its flaws before your application goes live. 

A report from Lineaje, which found that 70% of all software is open-source, focused its research on the Apache Software Foundation, calling it the “gold standard” of open-source. The popularity of the open-source brand attracts a lot of developers, but a good reputation is not always warranted. In this case, developers may be short-changing the quality of their code and adding significant risk to go with name recognition. Researchers found the following:

  • 82% of all open-source software components are inherently risky due to vulnerabilities, security issues, code equality or maintainability concerns
  • While about 68% of open-source software components are attestable, that means nearly one-third are not
  • 90% of Apache software is “unpatchable”.

“Developers do not have X-ray vision to see inside a software component they include, nor are most open-source selectors security experts,” Lineaje CEO and Co-founder Javed Hasan told AI Tech Park. That’s why it is necessary to take a closer look into the details of the open-source code and not just rely on popularity. 

The Lineaje study emphasizes the importance of CISA’s secure-by-design directive. Nearly two-thirds of the vulnerabilities found by the researchers have no patch, and because of the way Apache software is entwined with other open-source software, patches may be virtually impossible. By deploying secure-by-design protocols, developers could be forced to change the way they approach the code they rely on. They may need to forego popular or familiar libraries where the quality is not up to a higher standard. 

Open-source security and the supply chain

We can’t secure what we can’t see. It’s a phrase repeated over and over by cybersecurity analysts. What many security teams lack is visibility into the software supply chain, especially as you move deeper into the vendor pool.

Vulnerabilities in open-source software are increasing, according to a study from Synopsys. After analyzing 1,703 codebases, the study found that 76% were open-source, and in that code, 84% included an open-source vulnerability. That number increased by 4% from 2022.

When looking at the impact of those vulnerabilities in the software supply chain, a third of the study’s respondents said they experienced “exploit(s) that took advantage of known vulnerabilities in open-source software within the last 12 months.” 

Supply chain attacks in the open-source software space have been seen most often in repositories where a threat actor could insert a compromise into a repo or spawn a clone of a popular repo to the same effect, explained Mike Parkin, Senior Technical Engineer at Vulcan Cyber, in an email interview. 

“Less often, though sometimes with large consequences, they find a vulnerability that’s gone unnoticed in an existing library for years and manage to exploit that,” said Parkin. 

If a threat actor can compromise a library, products built on that library become vulnerable and subject to exploitation. 

“If a vendor is relying on an open-source library, it’s unlikely that there is any SLA with the library’s maintainer,” said Parkin. 

On the positive side, developers do have the ability to see the open-source code and fix it themselves. Also, if the library is widely used and/or actively maintained, a fix will often appear very quickly. 

But first, they need to know the vulnerability is there. For a direct vendor, or that vendor’s direct vendors, there should be some level of visibility into the open-source software and its risks. When the vendor chain gets longer, visibility is nearly impossible. An open-source vulnerability could end up being exploited anywhere along the supply chain but have a direct impact on your organization’s cybersecurity. And for libraries that aren’t very active, a vulnerability may not be patched for a very long time, and who knows where that risk could show up along the supply chain.

The need for SBOMs

The truth about open-source is that for all its benefits, it can be a cyber time bomb ready to go off at any moment. An open-source exploit for any organization is a problem, but an exploit within any part of the critical infrastructure could result in disaster. It is why the Biden Administration has focused on the software supply chain and the role of open-source. It is why CISA is promoting a Software Bill of Materials (SBOM), “a nested inventory, a list of ingredients that make up software components.”

“It’s like an ingredients list on a food package — it helps you understand what you’re getting and you can know whether it has something you’re allergic to. Or, in this context, something you may need to pay attention to. Sharing that knowledge is what the SBOM helps achieve,” said Parkin. 

“For example, if there’s an alert on a vulnerable library and you know because of the SBOM you have an application that may be affected, you can deploy compensating controls even before the application vendor publishes their own alert.”

Open-source is vulnerable — more vulnerable than most people realize. But it is also baked into our DevOps process. Understanding the risks, where they are and how to make better decisions around the code used should be part of the best practices used to secure your applications.

More from Risk Management

Back to basics: Better security in the AI era

4 min read - The rise of artificial intelligence (AI), large language models (LLM) and IoT solutions has created a new security landscape. From generative AI tools that can be taught to create malicious code to the exploitation of connected devices as a way for attackers to move laterally across networks, enterprise IT teams find themselves constantly running to catch up. According to the Google Cloud Cybersecurity Forecast 2024 report, companies should anticipate a surge in attacks powered by generative AI tools and LLMs…

Mapping attacks on generative AI to business impact

5 min read - In recent months, we’ve seen government and business leaders put an increased focus on securing AI models. If generative AI is the next big platform to transform the services and functions on which society as a whole depends, ensuring that technology is trusted and secure must be businesses’ top priority. While generative AI adoption is in its nascent stages, we must establish effective strategies to secure it from the onset. The IBM Institute for Business Value found that despite 64%…

Ermac malware: The other side of the code

6 min read - When the Cerberus code was leaked in late 2020, IBM Trusteer researchers projected that a new Cerberus mutation was just a matter of time. Multiple actors used the leaked Cerberus code but without significant changes to the malware. However, the MalwareHunterTeam discovered a new variant of Cerberus — known as Ermac (also known as Hook) — in late September of 2022.To better understand the new version of Cerberus, we can attempt to shed light on the behind-the-scenes operations of the…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today