Introduction
In December 2021, researchers disclosed a critical vulnerability in Apache Log4J 2, a popular library for logging errors and run-time information. Unlike vulnerabilities in applications, however, the Log4J flaw affected software whose developers did not explicitly include the component in their application. Research by Google at the time found more than 35,800 codebases, or artifacts, on the popular Maven repository affected by the vulnerability— more than 8%, compared to a median of 0.1% for the average advisory. In addition, the average Log4J import occurred five dependencies down, meaning the component included a library that included a library that included a library that included a library that used Log4J 2.¹
Such vulnerabilities—and the attacks that follow—are not uncommon. Approximately two years earlier, Russian nation-state actors compromised the development and deployment pipeline of network-management software provider SolarWinds, creating a backdoor in a software update that some 18,000 customers—including US government agencies— downloaded. The intelligence agency behind the hack used the foothold in those networks to compromise at least 250 networks at high-value targets.²
The two attacks represent two facets of the software supply-chain security of which developers need to be aware: Vulnerabilities in—or malicious attacks on—the components used to build applications, and attacks against the software and service providers that have privileged access to clients’ information.
Developers who use components without auditing their security run the risk of creating vulnerabilities in their own software and propagating attacks through the ecosystem.
Ensuring that software and services used by enterprises are free from known vulnerabilities requires a multi-prong strategy to lock down the myriad of processes and software components that make up your software supply chains. Companies need to trust the components and libraries used to create their own applications, track the provenance of code through the supply chain, understand their suppliers’ security processes, and conduct regular behavioral analysis on running software to make sure that the code is not behaving maliciously.
Over the four years from February 2015 to June 2019, software composition analysis firm Sonatype documented 216 software supply-chain 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.