The Problem with Supply Chains
Software supply-chain attacks have taken off in the past five years. Over the four years from February 2015 to June 2019, software-composition analysis firm Sonatype documented 216 software supplychain attacks. The following year, the number of attacks topped 900, and the year after that, the number of attacks jumped 650% to more than 12,000.³
In February 2021, a security researcher used typos in the names of common software components and packages to demonstrate that mistyped library names in software can lead to compromises.⁴ The researcher succeeded in spreading his code to more than 35 different companies, including Microsoft and Apple, using three different languages in what he termed a “dependency confusion” attack and others referred to as “namespace confusion.” By the next month, more than 10,000 copycats were found on the Node Package Manager (NPM) ecosystem, according to Sonatype, and Microsoft released a whitepaper on how to head off the attack.⁵
In another supply-chain attack, a ransomware group used three vulnerabilities in Kaseya’s Virtual System Administrator (VSA) servers to compromise a number of managed service providers and then used that access to infect downstream clients with ransomware. The attack showed the capability of software supply-chain compromises to become a force multiplier: While fewer than 60 MSP customers had been exploited by the three-vulnerability exploit chain, up to 1,500 companies who subscribed to those MSPs services were compromised.⁶
A software supply chain can be long and complex. The chain extends from applications down to open-source—or community-provided— components. The components can then include additional layers of open-source components.
Two Prongs of Software Supply-Chain Attacks
A software supply chain can be long and complex. The chain extends from applications down to open-source—or community-provided—components. The components can then include additional layers of open-source components.
Overall, attacks on the software supply-chain fall into three broad categories: Compromising the development pipeline, exploiting the software operations pipeline, and vulnerabilities in a subcomponents or dependencies. An example of an attack against the development pipeline includes dependency-confusion, where the attacker targets the software used by developers, while development pipeline attacks include Keseya and Codecov. Finally, vulnerabilities in dependencies and sub-components include Log4J and Spring4Shell.
And no matter where the vulnerabilities enter the software supply chain, maintainers and companies are slow to realize the security issues. Malicious packages introduced to the software supply chain were available for an average of 209 days before someone publicly reported the vulnerability.⁷ Meanwhile, software developers tended to move slowly as well, taking 205 days to deploy mitigations for vulnerabilities in their own software in 2021, up from 197 days in 2020.⁸
The result is that software supply-chain vulnerabilities are hard to detect for developers of the packages and slow to be deployed by maintainers and downstream users, making them an ideal vector for attackers and a difficult area of security for defenders.
A Backstabber’s Knife Collection
A seminal paper, Backstabber’s Knife Collection: A Review of Open Source Software Supply Chain Attacks, written by a team of European researchers collected 174 packages used in supply-chain attacks against open-source software between November 2015 and November 2019. The researchers found that each software ecosystem—the Python Package Index (PyPI), the Node Package Manager (NPM), and RubyGems—all had malicious code inserted into the supply chain. However, malicious modifications to PyPI components tended to be slower to be detected, while RubyGems tended to be quicker. In addition, malicious RubyGems tended to execute their payload during the runtime phase, while PyPI modifications tended to execute their malicious code during the installation phase. NPM packages split fairly evenly between the two tactics.
7 https://arxiv.org/pdf/2005. 09535.pdf (pg.11)