5 Examples of Dependency Confusion Attacks

Are you still running your package pipeline on default settings and grabbing libraries straight from public repos? Big yikes. That’s rolling out the red carpet for dependency confusion attacks to drop shady code into your project. 

It isn’t uncommon. Nearly half (49%) of organizations are exposed to the risks of a dependency confusion attack because they make the same mistakes. But what exactly is dependency confusion, and how do these attacks manage to infiltrate?

It comes down to your trust. You trust public repositories to be a source of secure, helpful packages and libraries. Attackers manipulate this trust to trick you and your automated tools into downloading fake packages riddled with malicious code. Thankfully, there are effective controls you can put in place to ensure only safe code enters your supply chain. Let’s review how these attacks happen, look at tools designed to help you identify and stop these threats, and share several strategies to boost your project’s defenses.

Table of contents

1. Defining and Understanding Dependency Confusion
2. How Do Dependency Confusion Attacks Work?

* Discovering Internal Dependencies

* Uploading Malicious Packages

* Compromising Your CI/CD Pipelines

3. 5 Real-World Examples of Dependency Confusion Attacks

* Microsoft’s 2021 Supply Chain Incident

* Malicious PyPI Packages in the Python Ecosystem/dd>

* Typosquatting in npm

* Small Business Supply Chain Risk

* Risks in Open-Source Libraries

4. Why Dependency Confusion Attacks Are More Common Than Ever
5. How Your Teams Can Detect and Prevent Dependency Confusion Attacks
6. Tools That Help Protect Against Dependency Confusion
7. Rethinking How You Trust the Packages You Use

Defining and Understanding Dependency Confusion

When adding external packages to your projects, your team may rely on package managers to fetch them from public repositories. This approach is much quicker, easier, and foolproof than manually fetching the packages. But what happens when a package with the same name exists simultaneously in a private and public repository? Attackers are discovering they can exploit this ambiguity and trick your systems into downloading a malicious version of the package instead of the one you want. It is called a dependency confusion attack.

Why Dependency Confusion Matters

Modern build pipelines have a major blind spot in how they pull in external code. Package managers prioritize convenience over security, so they automatically grab what they think is the right package without additional checks for integrity or source.

This type of attack is particularly insidious because it targets the automated nature of dependency management systems and leverages several possible avenues for ambiguity – version conflicts, namespace conflicts, and spelling mistakes. You should care because once a malicious package makes it into your software supply chain, it can compromise every system that uses that package. And that’s a path to stolen data or disrupted operations.

Once a malicious package infiltrates your software supply chain, it can compromise every system that relies on it, leading to stolen data or disrupted operations. Incorporating cyber risk quantification practices helps teams evaluate and prioritize these risks effectively.

Dependency Confusion Attack Sequence

How Do Dependency Confusion Attacks Work?

Understanding the workflow of these attacks provides valuable insights into their prevention.

Discovering Internal Dependencies

The first line of attack is to figure out what tools your company is using. Attackers scan for leaked package manifests, source code, error logs, open repositories, or public documentation. The goal is to collect information about your internal software libraries, including project names or specific packages.

Uploading the Malicious Packages

They then make fake packages that mimic the naming conventions, versioning, and metadata packages you use. Unfortunately, the sheer volume of packages on public package managers and repositories makes it difficult for oversight mechanisms and processes to notice these fake packages.

Compromising Your CI/CD Pipelines

Your CI/CD system reads configuration files during the build process to determine dependencies to download. Without proper safeguards, malicious packages can execute harmful code, exposing your system to remote code execution vulnerabilities.

5 Real-World Examples of Dependency Confusion Attacks

Let’s look at some actual cases that show just how tricky and urgent it is to guard against dependency confusion:

1. Microsoft’s 2021 Supply Chain Incident

In 2021, a security researcher named Alex Birsan revealed a big loophole in Microsoft’s supply chain when he uploaded decoy packages to npm that matched Microsoft’s internal dependencies. Although these were just benign test packages, they pointed out a serious risk. 

Microsoft used the –extra-index-url argument in its CI/CD scripts. This argument prioritizes public packages with higher version numbers; Birsan’s test packages are pulled instead of the intended packages. Following Birsan’s report, Microsoft changed its dependency verification protocols to improve namespace integrity checks in their CI/CD workflows.

2. Malicious PyPI Packages in the Python Ecosystem

The Python Package Index (PyPI) is a significant hub for Python developers. Top packages like boto3 receive over 1 billion downloads monthly, and because of their popularity, they are continually targeted for dependency confusion attacks. 

PyPI package down stats

For example, in 2024, researchers discovered two fake packages using DLL side-loading to escape detection and execute harmful code. Developers and development teams frequently add packages from PyPI; however, they may not realize the risk of code execution attacks.

3. Typosquatting in npm

Typosquatting is a technique hackers use to exploit potential typing errors. They deliberately create packages with names similar to popular ones, like “lodas” instead of “lodash,” hoping developers will mistype and inadvertently install their malicious package. While it’s impossible to eliminate typing errors,  always double-check the spelling and version of any package before adding it as a dependency.

4. Small Business Supply Chain Risk

Pretend that a small business that uses an internal library called “datawidget”.  If a hacker discovers this dependency, they could upload a harmful version of “datawidget” to a public repository. If the business’ CI/CD pipeline isn’t set up to prefer internal sources first, it might download this fake package by mistake.

5. Risks in Open-Source Libraries

In April 2024, a dependency confusion vulnerability was discovered in the open-source Cordova App Harness project. The vulnerability opened the project to attack by allowing threat actors to create a malicious version of the  `cordova-harness-client` library with a higher version number. This library is an archived Apache project, and, as such, it is no longer maintained or receiving security patches. Despite this, the library continues to be downloaded, increasing the potential risk.

Why Dependency Confusion Attacks Are More Common Than Ever

The increased severity of this attack vector is due to several key factors that have become more prevalent in recent years.

• Complexities in Managing Dependencies. Projects now rely on hundreds of external and internal libraries. As projects scale, tracking the origin and security of every package becomes more difficult.
• Prevalence of Open-Source Software/Resources. Open-source libraries are everywhere. Developers love their flexibility but often rush to integrate them, sometimes skipping security checks to save time. 
• Lack of Awareness Among Teams. Many dev teams don’t fully understand that attackers can exploit packages and dependencies via dependency confusion attacks. Without training, teams may miss critical steps like verifying package sources.

How Your Teams Can Detect and Prevent Dependency Confusion Attacks

Securing your supply chain and effectively preventing dependency confusion requires a layered strategy combining preventive steps and constant monitoring. These strategies include –

1. Secure Your CI/CD Pipelines

When fetching dependencies, prioritize internal repositories and verify their authenticity. Adopting frameworks like ISO 27001:2022 controls can provide a structured approach to securing your CI/CD pipelines and protecting against vulnerabilities. 

2. Pin and Scope Dependencies

Don’t fall victim to higher version prioritization and namespace conflicts. Specify exact versions in your project’s dependency files to remove any ambiguity. For example, instead of using version ranges in your package.json for npm, specify 2.1.3 rather than ^2.1.3. You can also prefix the name of a package with your organization or project name, such as @company/package, to reduce the chance of overlap with public packages.

You can also prefix a package name with your organization or project name, such as @company/package, to reduce the chance of overlapping with public packages. 

To ensure security and consistency, specify exact versions in your dependency files and implement naming conventions to avoid overlap with public packages. Leveraging digital process automation strategies can help standardize dependency management, reduce manual errors, and ensure smoother workflows across development pipelines.

3. Monitor Public Repositories

Deploying monitoring tools is a great way to scan public repositories for suspicious package releases that could affect your ecosystem. Automated security scanners can alert your team to unusual activity, such as the sudden appearance of packages similar to your internal names or unexpected updates to rarely used packages.

To prevent security risks like JavaScript injections, cryptographically verify or cross-reference dependencies with an approved package registry before integrating them into your builds.

4. Audit Dependencies Regularly

Schedule and execute manual checks of all dependencies every quarter to catch any subtle issues or inconsistencies. At other times, you should leverage automated tools like SpectralOps for frequent, regular scans.

Regular audits of all dependencies are critical to catching subtle issues or inconsistencies. Establishing a well-defined information security policy ensures your team adheres to best practices for dependency management and secure software development.

Securing Supply Chain Against Dependency Confusion

Tools That Help Protect Against Dependency Confusion

Various tools are available to help secure your software supply chain and assist your team in the fight against dependency confusion attacks.

Automating Security

SpectralOps is designed to prevent dependency confusion by providing real-time alerts that notify teams of suspicious activities or vulnerabilities within their dependencies. It easily integrates with CI/CD platforms like GitHub, GitLab, and Jenkins.

Other Tools for Dependency Management

Other valuable tools in this area include Dependabot, npm audit, and various PyPI scanners:

• Dependabot: Automatically updates your dependencies to reduce the risk of security vulnerabilities.
• npm audit: Analyzes your Node.js projects to identify security issues.
• PyPI scanners: Actively search for vulnerabilities within Python packages.

Choose the Right Tools

Use tools that align with your specific project needs and operational environment. Evaluate features, ease of integration, and the ability to scale as your projects grow.

Rethinking How You Trust The Packages You Use

The threat of dependency confusion attacks highlights the critical need to monitor your software supply chain closely. Establishing a security-conscious culture and equipping your team with the necessary tools to mitigate this risk is essential. Check out Spectral for industry-leading detection features that fit right into your existing setup, helping you stay ahead of security threats. It offers real-time alerts and tools to monitor dependencies for suspicious activity. Don’t wait for the next attack – be proactive. Let Spectral help keep your projects safe today!