The rash of supply chain attacks that have emerged in the last year hit some of the largest commercial software companies on the planet, causing widespread ripple effects for tens of thousands of organizations. But beyond the huge headline-grabbing incidents such as SolarWinds, there is a low hum of constant, smaller attacks on open source software projects that can cause serious issues for not just a given project’s maintainers and users, but also the maintainers and users of downstream projects that depend upon it.
The most recent example of this problem is the attack that compromised the Codecov code-coverage tool’s bash uploader script. That incident affected not just the companies that relied on the tool itself, but also many of the countless downstream open source projects that use it. The attacker had access to the script for more than two months and had the ability to steal sensitive data from customers’ environments.
“The actor gained access because of an error in Codecov’s Docker image creation process that allowed the actor to extract the credential required to modify our Bash Uploader script,” Jerrod Engelberg, CEO of Codecov, said in a statement.
There are plenty of other quieter incidents that stay below the radar, including simple typosquatting attacks that try to impersonate popular packages, and more complex attempts to insert backdoors into projects.
“There are two problems with open source software security. First, it’s open source, and second, it’s software. All software has bugs, whether it’s written by me or by you or by someone you’ve never met,” said Dan Lorenc, a software engineer at Google, during a talk at the company’s Open Source Day of Security event Thursday.
“Sometimes, just because it's free doesn’t mean it’s free to use. It can cause more problems than it’s worth. Anyone who’s spent time on the Internet knows not everyone is nice, there are people out there trying to insert bugs. Very few people are looking at the source code. The source code is transparent, but the way that people use it is opaque.”
The tree of dependencies in any supply chain can be complex, even for the simplest pieces of software, and discovering what those dependencies are can be difficult, if not impossible. That lack of transparency makes it hard for organizations to understand the security risks that a piece of open source software may bring with it, a problem that Google is trying to address with a new tool called Open Source Insights. The site displays a visualization of the dependencies for a given package, lists any security advisories affecting it, other packages that depend upon that project, and allows users to compare the various versions of the package. It’s an experimental project, but Open Source Insights could provide enterprises with a deeper understanding of what risks they may be taking on.
“The software packages that a large project depends on might update too frequently to keep a clear picture of what is happening. And those packages, in turn, can change their dependencies to provide new features or fix bugs. Security problems and other issues can arise unexpectedly in your project as a result, and the scale of the problem can make it all difficult to manage. Even a modest OSS project might depend on hundreds of packages,” Google said.
Looking at the dependencies for open source projects is just one step toward understanding the security impact they can have and improving the security of the open source supply chain. Enterprises need to understand exactly what open source applications they’re using and what the potential risks for each one are.
“Know what you use. This sounds obvious, but it’s not always that easy. Look through the vendor tree and check the dependencies. You might trust those dependencies, but if you don’t trust the whole transitive tree of their dependencies, it can get out of control,” Lorenc said.
He also encouraged users of open source software to contribute upstream whenever possible by helping with patches or other fixes.
“Security isn’t a priority for open source developers or the average developer in general. It’s an afterthought. We need to make it easier,” Lorenc said. “We need to build new tooling and crypto and gather more data to secure the open source supply chain.”