Security Teams Need to Address One of the Biggest Software Supply Chain Risks: Open Source
One of the biggest threats to software supply chain security is open source software applications and components. Many enterprises and small businesses have come to rely on open source solutions, and they are an important part of IT strategies today. But vulnerabilities in open source software present a risk because they can provide cyber criminals with a way to carry out attacks.
“Attackers can easily deliver malware inside of [open source] packages,” said Jossef Harush Kadouri, head of software supply chain security at Checkmarx, speaking at a session held at the recent RSA Conference virtual seminar on supply chain security.
Kadouri said he has been working in software supply chain security for about three years. “From a developer’s perspective, when I started this it was quite clear that no one was actually checking [what’s in] our open source packages,” he said.
Now, Kadouri and teams of researchers, software engineers and developers have a mission to track attackers that are using open source software to launch supply chain attacks.
He noted that SLSA, a set of incrementally adoptable guidelines for supply chain security established by industry consensus, has created a framework that identifies three main categories of software supply chain risks. These are source threats, build threats and dependency threats.
The teams at Checkmarx are focused on finding and tackling dependency threats. “We do that by monitoring the open source ecosystems” using a variety of tools, Kadouri said. “Basically we audit evidence, we collect metadata, we index the actual artifacts and then we initiate an analysis process.”
The teams check for software contributor reputation, malicious behavior and threat intelligence as part of its initial analysis. They then detonate the actual packages of software in a custom made sandbox to see if there is communication with a specific server or endpoint target.
From there the teams conduct a manual review of the results, and if they find suspicious activity they report the findings to ecosystem security teams because they don’t have permission to remove packages or stop users from downloading malware via open source packages. They also publish the results through blogs and publications.
The teams actively monitor the open source ecosystem and over time it has continued to grow. “It makes a lot of sense; generally speaking everyone uses open source,” Kadouri said. “The majority of open source delivers great content and everyone’s enjoying that, so whenever developers are asking for specific open source packages they say, ‘okay, I want this package’ [and] they don’t think about the side effects.”
It’s especially important for developers and others to keep in mind that the popular open source projects are not necessarily completely secure. Kadouri keeps a list of open source software packages that he regularly updates with packages that have been shown to deliver malware to unsuspecting users.
Among the key takeaways from the session were that organizations need to reduce the excessive trust in open source; vet their open source software, including checking packages; consider integrating commercial threat intelligence feeds into their software development lifecycle to help prevent malware in artifact services and build server; and to remember that even popular open source products can deliver malware.
