Recent findings by security researchers at SonarSource showed multiple security vulnerabilities in popular package managers, including Pip, Yarn, Composer, and others. Package managers, though, are not the only weak link in the open source security chain. InfoQ has spoken with Sonatype CTO Brian Fox.
Paul Gerste, vulnerability researcher at SonarSource, describes a number of attacks that allow a hacker to compromise a developer's machine by installing a malicious package. Gerste uncovered a command injection vulnerability in Composer, argument injection vulnerabilities in Bundler and Poetry, and untrusted search path vulnerabilities in Yarn, Pip, Composer, and others.
SonarSource research confirms the software supply chain is a critical component of many organizations and is essential to its secure operation.
Most of the package managers have been already patched at the time of writing, except for Pip and Pipenv, but updating is not the end of the story if you are serious about security, says Gerste:
Remember to update all your tools regularly and stay cautious when handling files from unknown sources. We strongly advise against using package managers on untrusted code bases, even with security features like disabling the execution of scripts.
Gerste's advice is worthy of serious consideration, even more so in light of what happened earlier this year, when the maintainer of two very popular JavaScript packages, colors and faker, corrupted his own files, impacting thousands of apps and millions of users. Marak Squires explained his act of sabotage as a protest against the exploitation of free work which many companies somehow take for granted. This was a reminder of the inherent fragility of a development pipeline building on open source software.
InfoQ has spoken with Brian Fox, CTO at DevSecOps company Sonatype to better understand the relation between open-source and supply chain security.
InfoQ: Open Source is a huge success story that has changed the way software is developed, so much that large parts of the software industry have come to depend on it. The recent issue with npm libraries "colors" and "faker" being sabotaged by their maintainer seems to reveal Open Source, and hence the software industry at large, is a giant with feet of clay. Is there a sustainability issue at play here?
Brian Fox: Many of the more popular Open Source projects are actually comprised of larger teams of very experienced developers. There are, however, a lot of smaller projects that find popularity, like colors and faker, that are maintained by a single person.
The reason behind this is essentially twofold; first, for projects of all sizes, there are many more users / free riders that consume the software and never get involved. Second, there isn’t enough visibility and control at organizations to help direct their developers in what projects to choose.
This is what we tend to refer to as Hygiene of a project. Is it sponsored by a foundation such as the Apache Software Foundation, Eclipse, The Linux Foundation? If so, it likely has oversight in place to ensure sustainability. Does the project have a track record of quality software? How active is the community?
Visibility and policy around these types of attributes would help organizations better empower their developers to choose components that have less inherent risk.
InfoQ: While Squires' actions were by no means a reasonable way to protest, it is undeniable that some parts of the open source community may empathize with his motives to some extent. What could contribute to reducing maintainers' burnout?
Fox: You’re right, some parts of the community empathize with his motives. Last month, the Apache Software Foundation called out downstream businesses that benefit without actively contributing in the wake of Log4j — another recent flashpoint in the community.
What they suggest and I agree with is to avoid placing additional burdens onto maintainers that are already doing work. The best way they can help is by giving them a hand. It’s a good way to give back to the community and would earn those companies a lot more respect.
InfoQ: What are effective practices for companies to minimize the risk of disruption in their CI pipelines due to malicious or vulnerable packages, or even worse a malicious/vulnerable dependency making it to production?
Fox: Create and continuously update a software bill of materials and work with a tool that includes software composition analysis (SCA). SCA is about looking at all the components in a project and determining the potential risk from those components. SCA (Sonatype included) is meant to find and identify risk in your applications.
These tools should be automated to monitor components across the entire software development lifecycle. The fact that so many organizations were so slow to respond to the Log4j incident reminds us that many companies are not able to handle the basics.
It’s an absolute priority to ensure your organization has a robust view of its in-use components so you can respond to disclosures quickly, but it’s also essential that organizations recognize new, and intentionally malicious threats from the jump. These kinds of components are designed to cause harm immediately, and usually don’t even compile or pass tests when a developer includes them. For that reason, the malicious components are often replaced before code is checked in or released - where traditional application security scans would be able to catch them.
Not recognizing these components as harmful early on then creates a substantial risk that our current scanning and remediation protocols can’t solve. An example might be that a developer accidentally grabbed a bad component, had a back door or data exfiltrated, then subsequently "fixed the issue" before moving on, without realizing the damage was already done.
