The Evolution of the Software Supply Chain Attack

Introduction

Hello, my name is Catherine, and I’m the Global Director of Solutions Architecture at Sonatype. At Sonatype, I spend my days combating software supply chain attacks, which primarily involve influencing the code you don't own but use in your software. These attacks have evolved as our practices around software development have evolved. In this article, I’ll walk you through the evolution of software supply chain attacks and strategies for defending against them.

Open Source Dominance

Software has evolved dramatically, especially with the rise of open source. Open source components now make up about 75-90% of an application's codebase, depending on the report. These components include libraries, transitive dependencies, containers, and operating system packages. While open source accelerates development, it also introduces new risks that attackers exploit.

The Evolution of the Attack

Attacks Using Known Vulnerabilities

The basic form of software supply chain attack uses known security vulnerabilities in open source components. These vulnerabilities exist because developers often forget to update their dependencies. For instance, a Java project might contain hundreds of modules, each potentially carrying vulnerabilities.

A notable early example is the 2015 Commons Collections deserialization vulnerability, which led to ransomware being installed on systems like those at Hollywood Presbyterian Hospital. Despite being well-known, 80% of downloads for this component remained vulnerable a year later.

Another example is the 2017 Struts 2 remote code execution vulnerability. This severe vulnerability was discovered and exploited in just a few days, affecting multiple organizations like Equifax, Canada's Revenue Agency, the Okinawa Power Agency, and India's Aadhaar system. Even today, 65% of Struts downloads are of the vulnerable version.

Introducing Malicious Code

The next evolution involves inserting malicious code directly into open source projects. In 2018, the Event Stream component was compromised by a contributor who injected malicious code. Though the vulnerability was quickly noticed, a previously injected vulnerability went undetected, leading to a cryptocurrency wallet compromise.

This type of attack highlights the risk of backdooring upstream projects rather than waiting for new vulnerabilities to emerge.

Predictive Trends

Software supply chain attacks often predict each other. For example, a 2018 Medium article about harvesting credit card numbers using bogus JavaScript anticipated an actual attack on British Airways later that year. This attack manipulated JavaScript on BA's payment page to steal credit card information.

Advanced Threats

New threats continue to emerge. Recently, GitHub described a type of attack called Octopus Scanner that targets the NetBeans IDE. This malware embeds itself into the development environment and infects all output files, leading to widespread infections.

Defense Strategies

Thankfully, defenses have evolved as well. Tools from Sonatype and others help manage open source components by:

Identifying known vulnerabilities.
Automating version upgrades.
Scanning your entire codebase for vulnerabilities.

However, attackers are continually adapting, and new strategies are required. Ensuring your code is 100% open-source canonical and monitoring your development environment for infections is becoming increasingly critical.

Conclusion

As software supply chain attacks evolve, so must our defenses. Developers must look beyond known vulnerabilities and ensure the integrity of their development environments. Stay vigilant, use advanced tools, and always be prepared for future iterations of these attacks.

Keywords

Software Supply Chain Attack
Open Source
Vulnerabilities
Development Environment
Sonatype
Dependency Management
Event Stream Attack
Struts 2 Vulnerability
Octopus Scanner
NetBeans

FAQ

Q1: What is a software supply chain attack?
A1: A software supply chain attack involves manipulating the code you don't own, typically open-source components, which are part of your software.

Q2: How prevalent are open source components in modern applications?
A2: Open source components can make up 75-90% of an application's codebase.

Q3: Can you give an example of a well-known software supply chain attack?
A3: The 2017 Struts 2 remote code execution vulnerability, which affected organizations such as Equifax, is a prominent example.

Q4: How do attackers introduce malicious code into open-source projects?
A4: Attackers sometimes contribute to open-source projects with seemingly benign code, eventually injecting malicious code once they gain committer rights.

Q5: What tools can help defend against software supply chain attacks?
A5: Tools from companies like Sonatype can identify known vulnerabilities, automate version upgrades, and scan your codebase for threats.

Q6: Why is it important to ensure code is 100% open-source canonical?
A6: Ensuring code is 100% open-source canonical helps in verifying that there are no unknown or slightly modified components that might contain vulnerabilities.

Q7: What recent type of attack targets development environments?
A7: An attack called Octopus Scanner targets the NetBeans IDE by embedding itself in the project directory and infecting build outputs.