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.
