Securing the Open Source Software Supply Chain
Recent findings from SonarSource security researchers showed several security vulnerabilities in popular package managers including Pip, Yarn, Composer and others. Package managers are not the only weak link in the open source security chain, however. InfoQ spoke with Sonatype CTO Brian Fox.
Paul Gerst, a 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 discovered 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 that the software supply chain is a critical part of many organizations and is critical to its secure operation.
Most package managers have already been fixed at the time of writing, except for Pip and Pipenv, but updating isn’t the end of the story if you’re serious about security, says Gerste:
Remember to update all your tools regularly and be careful when handling files from unknown sources. We strongly advise against using package managers on untrusted codebases, even with security features such as disabling script execution.
InfoQ spoke with Brian Fox, CTO at DevSecOps Sonatype to better understand the relationship 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 problem with the npm “colors” and “faker” libraries sabotaged by their maintainer seems to reveal that Open Source, and therefore the software industry as a whole, is a giant with feet of clay. Is there a durability issue at play here?
Many of the most popular Open Source projects are actually made up of larger teams of very experienced developers. There are, however, many smaller projects that are finding popularity, such as colors and scythes, which are maintained by one person.
The reason behind this is basically twofold, firstly, for projects of all sizes there are far more users/free riders consuming the software and never getting involved. Second, there is not enough visibility and control in organizations to help guide their developers in which projects to choose.
This is what we tend to call the hygiene of a project. Is it sponsored by a foundation such as 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, there’s no denying that parts of the open source community can understand his motives to some degree. What could help reduce maintainer burnout?
You’re right, some parts of the community sympathize with his motives. Last month, the Apache Software Foundation called out downstream companies that benefit without actively contributing to the Log4j suite – another recent flashpoint in the community.
What they suggest, and which I agree with, is to avoid placing additional burdens on maintainers who are already working. The best way they can help is to give them a hand. It’s a good way to give back to the community and earn much more respect for these companies.
InfoQ: What are effective practices for companies to minimize the risk of disruption to their CI pipelines due to malicious or vulnerable packages, or even worse, a malicious/vulnerable dependency moving into production?
Create and continuously update a software BOM and work with a tool that includes software composition analysis (SCA). SCA involves looking at all the components of a project and determining the potential risk of those components. SCA (including Sonatype) is intended to find and identify risks in your applications.
These tools should be automated to monitor components throughout the software development lifecycle. The fact that so many organizations were so slow to respond to the Log4j incident reminds us that many companies are unable to handle the basics.
It’s a top priority to ensure your organization has a solid view of its components in use so you can respond quickly to disclosures, but it’s also critical that organizations recognize new and intentionally malicious threats as soon as they arise. departure. These types of components are designed to cause damage immediately and usually do not compile or even pass tests when a developer includes them. For this reason, malicious components are often replaced before the code is archived or released – where traditional application security scans might detect them.
Failure to recognize these components as harmful from the outset then creates substantial risk that our current scanning and remediation protocols cannot address. An example might be that a developer accidentally grabbed a bad component, had a backdoor or exfiltrated data, then “fixed the problem” before moving on, not realizing the damage was already done. .