A Rapid Rise in Open Source Supply Chain Attacks
Table of Contents
Changing Attack Methods
Open source supply chain attacks can lead to widespread data breaches and extortion efforts and have evolved with new attack vectors by threat actors. “Legacy” supply chain exploits typically focused on publicly disclosed open source vulnerabilities. This was demonstrated in the Equifax data breach in 2017 which relied on an Apache Struts vulnerability (CVE-2017-5638) and led to the disclosure of over 140 million private records.
Attackers have more targets and methods available due to an increasing rise in the use of open source repositories from npm, PyPi, Maven, NuGet, and many others. These “next generation” supply chain attacks involve attackers not waiting for public exploits to be disclosed. These newer supply chain attacks instead inject malicious code into open source projects or publish malicious packages onto public repositories:
- Namespace Confusion (Dependency Confusion): attackers publish malicious packages to public repositories. These packages share the same name or are a newer version of a commonly used package, which will often be automatically fetched by pipeline build tools.
- Typosquatting: attackers publish malicious packages with the misspelled names of commonly fetched packages. Developers accidently mistype the package name and install the misspelled malicious package.
- Malicious Source Code Injection: attackers inject malicious code into open source project repositories. A notable example of this is the SolarWinds Orion attack, where attackers injected the “Sunburst” backdoor into the Orion platform software.
In 2021 President Biden issued two Executive Orders related to securing software supply chains. Following the Colonial Access Pipeline attack, the second Executive Order was issued in May 2021 and specifically calls for the use of “Software Bill of Materials” or SBOM: “a nested inventory, a list of ingredients that make up software components. ” SBOM aims to address the fact that most software relies on open source components like libraries, executables, and source code. Listing all these components helps software developers keep components up to date and respond to new vulnerabilities. SBOM also helps software customers determine if their software is at risk. The EO led to best practices like SBOM and various other supply chain security best practices that can be broadly applied. The Enduring Security Framework (ESF) specifically outlines the best practices for securing the software supply chain in a 3-part series addressing customers, developers, and suppliers:
These best practice supply chain guides were published by the NSA, CISA, and the Office of the Director of National Intelligence (ODNI) in September, October, and November 2022 and can be found here.
The ESF outlines how software suppliers, customers, and developers share overlapping responsibilities for securing the software supply chain. Suppliers share a role in both secure software development and also the secure delivery of software to the customer, including updated releases and patches. Likewise, customers must ensure they follow best practices when acquiring, deploying and operating new software products.
Below are two examples from the ESF of software customer and supplier best practices.
Customers are recommended to verify the attestation of the software– ensure the software is intact and trustworthy, with tools like SBOM and file hashes. Customers are also expected to stay in communication with suppliers about changes of ownership and follow best practices for deploying new software.
Software suppliers must provide accurate information to customers related to new software patches and cybersecurity threats. Suppliers aim to prevent attackers from using vulnerable software by keeping their customers up to date on these patches and threats.
These are just a few examples of supply chain best practices. For more comprehensive guidance check the official ESF guides for suppliers, customers, and developers.