Updated from original May 29th post.
Making a salad for lunch or dinner? What ingredients do you use? Lettuce, carrots, onions, tomatoes, dressing? If you just refer to the list of ingredients, you know what you've used, but not the quality of the ingredients themselves. In the realm of software component analysis (SCA), the difference between evaluating a list of ingredients by name (the manifest) and a full evaluation of the binaries themselves (advanced binary fingerprinting) can provide very different results. And when it comes to DevSecOps practices, those results can mean the difference between shipping high quality code and being breached tomorrow.Reports are just surfacing about a new form of software supply chain attack that targets open source software projects on GitHub. So far, 26 open source projects have been impacted by the attacks, leaving developers relying on those projects susceptible to the malware that has been injected into the code.
According to GitHub's security lab,
"On March 9, we received a message from a security researcher informing us about a set of GitHub-hosted repositories that were, presumably unintentionally, actively serving malware. After a deep-dive analysis of the malware itself, we uncovered something that we had not seen before on our platform: malware designed to enumerate and backdoor NetBeans projects, and which uses the build process and its resulting artifacts to spread itself."
The malware is being referred to as the Octopus Scanner.
For several years, our annual State of the Software Supply Chain Report has detailed several forms of OSS supply chain attacks including malicious code injection, stealing project credentials, and typosquatting, but Octopus takes on a new approach. Rather than target the OSS project code itself, this attack targets the tools developers are using the build their code.
Those leading DevSecOps practices speak of "shifting security left". At Sonatype, we've continuously refined that notion to deliver security information as far left as possible. We were the first to introduce automated component analysis inside artifact repositories, the first to provide automated component intelligence to developers inside their IDE, and the first to offer automated perimeter security for OSS downloads. We're also the only SCA provider on the market to offer Advanced Binary Fingerprinting (ABF) that includes a lesser known capability that we refer to as "partial matching". Partial matching enables users of our Nexus platform to see when any aspect of a component has been changed. A component may go by the same name and version number according to an analysis of the package manifest, but the underlying code base could have been changed.
We often see this form of binary change when crafty developers are trying to workaround their OSS governance policies. Let's say they really like using jquery 3.2 but their OSS policy only allows the use of jquery 3.4 or greater. Why not just change the name of the 3.2 binary to show 3.5 and you safely avoid the OSS governance policy? Yes, we've seen developers do this a few times. That substitution might not be so bad as a malware injected binary, but partial matching would catch it nonetheless.
Now, back to Octopus Scanner. The malware can inject its malicious payload into any newly built JAR file. While the manifest would look no different, the underlying code has changed and anyone using that OSS component within their application builds is now at risk.
Users of our Nexus platform need not be too concerned about approaches like these. If you happen to use abnormal or potentially malicious components, our continuous analysis of your binaries will flag it as a partial match and alert your developers and security team of the issue. As usual, you will be guided to alternative safer versions of that component available for use.
The Octopus Scanner malware validates why we’ve been focused on analyzing the binaries since 2011 and not taking the word of the manifest. Adversaries are well aware of the unbridled use of open source components by every developer around the world. While open source is awesome and accelerates all of our innovations, it does come with a responsibility to use the best, highest quality, and most secure components available. It's been and will continue to be our mission to support developers in that responsibility, and to help us all stay one step ahead of our adversaries.