Software Supply Chain Attacks: How Malicious Packages Infiltrate npm and PyPI

Modern software applications are not built from scratch. They are assembled from hundreds — sometimes thousands — of open-source packages downloaded from public registries like npm (JavaScript), PyPI (Python), Maven Central (Java), NuGet (C#), and RubyGems (Ruby). This dependency-heavy development model has revolutionized productivity, but it has also created a massive attack surface that adversaries are increasingly exploiting.

A software supply chain attack occurs when an attacker compromises a component that is trusted and consumed by downstream applications. Instead of attacking your application directly, the attacker poisons a library that your application already depends on. When you install or update that library, the malicious code executes in your environment with whatever permissions your application has — access to databases, file systems, network resources, environment variables, and cloud credentials.

The consequences are severe: attackers gain a foothold inside your infrastructure through a vector that bypasses traditional perimeter defenses entirely. Firewalls, WAFs, and network segmentation offer no protection when the malicious code is delivered as a trusted dependency inside your build pipeline.

Attack Vectors: How Attackers Weaponize Package Registries

Supply chain attacks exploit the trust that developers place in package registries and the convenience of automated dependency management. There are several distinct attack vectors, each with its own mechanics and countermeasures.

Typosquatting

The typosquatting attack surface is enormous because package registries use a flat namespace with minimal naming restrictions. For a popular package like lodash, attackers can register lodahs, l0dash, lodash-utils, or lodassh. For requests on PyPI, variants like requesrs, requets, python-requests, and request have all been observed hosting malicious code.

# Developer intends to install "requests" but makes a typo
pip install requesrs

# Or in package.json, a developer misspells a dependency
{
  "dependencies": {
    "lodassh": "^4.17.0",     // Typosquat of "lodash"
    "cross-env": "^7.0.0",     // Legitimate
    "crossenv": "^7.0.0"       // Typosquat - contains crypto miner!
  }
}

The crossenv incident in 2017 was one of the first widely publicized typosquatting attacks on npm. A malicious package named crossenv mimicked the popular cross-env package (note the missing hyphen). When installed, it stole environment variables — which commonly contain API keys, database passwords, and cloud credentials — and transmitted them to an attacker-controlled server.

Dependency Confusion

This attack was famously demonstrated by security researcher Alex Birsan in 2021, who successfully injected code into the build pipelines of Apple, Microsoft, PayPal, Shopify, Netflix, Tesla, Uber, and over 35 other major organizations. By publishing higher-versioned packages to npm and PyPI that matched the names of internal packages he discovered in public configuration files, his proof-of-concept code executed inside their corporate networks, earning him over $130,000 in bug bounties.

# Company's internal .npmrc configuration
registry=https://npm.internal.company.com

# Company's package.json references private packages
{
  "dependencies": {
    "company-auth-utils": "^1.2.0",   // Internal package (v1.2.0)
    "company-data-models": "^2.0.0"    // Internal package (v2.0.0)
  }
}

# Attacker discovers package names and publishes to public npm:
# "company-auth-utils" v99.0.0 (malicious) on public npm
# Package manager may fetch v99.0.0 from public npm
# instead of v1.2.0 from internal registry!

Defenses Against Dependency Confusion

# .npmrc - Pin scoped packages to internal registry
@company:registry=https://npm.internal.company.com
//npm.internal.company.com/:_authToken=${NPM_INTERNAL_TOKEN}

# All @company/* packages will ONLY be fetched from internal registry
# Public npm cannot serve packages in the @company scope

Chainjacking (Maintainer Account Takeover)

This vector is particularly dangerous because it poisons a package that is already trusted and widely installed. Unlike typosquatting, where the victim must make a mistake, chainjacking targets packages that are already in use. The malicious update flows through normal update channels — CI/CD pipelines, automated dependency updaters, and developer machines running npm update.

Case Study: The event-stream Incident

The event-stream incident of 2018 remains the most instructive example of a sophisticated supply chain attack targeting the npm ecosystem. It demonstrates how social engineering, patience, and multi-layered obfuscation can compromise widely-used packages.

The event-stream attack was groundbreaking in its sophistication. The attacker targeted a specific application (Copay) through an upstream dependency (event-stream) that Copay used, making the attack a targeted supply chain compromise rather than a mass-exploitation attempt. The encrypted payload ensured that the vast majority of event-stream users — and any security researchers analyzing the package — would never see the malicious behavior.

Recent Large-Scale Campaigns

Supply chain attacks have accelerated dramatically since the event-stream incident. Modern campaigns are more frequent, more automated, and harder to detect.

npm Campaigns (2023-2025)

• Preinstall script attacks — Packages containing malicious preinstall scripts that execute immediately when the package is installed, before the developer writes a single line of code that imports it. These scripts have been observed stealing SSH keys, browser cookies, cryptocurrency wallets, and cloud credentials.
• Protestware — Maintainers of popular packages intentionally modifying their code for political protest purposes, as seen with the node-ipc and colors incidents. While motivations differ from criminal actors, the impact on downstream users can be equally destructive — the node-ipc modification deliberately overwrote files on systems with specific geolocated IP addresses.
• Manifest confusion — Exploiting discrepancies between what npm displays on the package page (parsed from the registry manifest) and what is actually in the tarball that gets installed, allowing attackers to hide malicious dependencies that do not appear in the publicly visible package.json.

PyPI Campaigns (2023-2025)

• Setup.py execution attacks — Python's packaging system historically executed setup.py during installation, giving attackers arbitrary code execution at install time. Packages mimicking popular data science libraries (numpy, pandas, scikit-learn variants) have been found with information-stealing payloads.
• Steganographic payloads — Malicious packages embedding encrypted payloads inside image files or binary data that are decoded and executed at runtime, evading pattern-based detection that focuses on Python source code.
• Multi-stage loaders — Packages that appear clean on installation but download and execute additional payloads from remote servers after a delay, making static analysis of the package itself insufficient for detection.

How SCA Scanning Protects Against Supply Chain Attacks

Software Composition Analysis (SCA) is the primary technical defense against supply chain attacks. SCA tools analyze your application's dependencies to identify vulnerabilities, license risks, and indicators of malicious packages.

Dependency Graph Analysis

SCA tools build a complete dependency graph by parsing manifest files and lock files. This reveals not just your direct dependencies but every transitive dependency — the dependencies of your dependencies, often going six or seven levels deep. A typical application with 50 direct dependencies may have 500 or more transitive dependencies, each of which represents a potential supply chain attack vector.

# SCA dependency tree analysis output
your-application@1.0.0
+-- express@4.18.2
|   +-- body-parser@1.20.1
|   |   +-- bytes@3.1.2
|   |   +-- depd@2.0.0
|   |   +-- raw-body@2.5.1
|   +-- cookie-signature@1.0.6
|   +-- qs@6.11.0
+-- axios@1.6.0
|   +-- follow-redirects@1.15.3   // Known CVE: SSRF via redirect
|   +-- form-data@4.0.0
+-- lodash@4.17.21

Total: 12 direct dependencies, 147 transitive dependencies
Vulnerabilities found: 3 (1 Critical, 1 High, 1 Medium)
Malicious package indicators: 0

Vulnerability Matching

SCA tools cross-reference every dependency against multiple vulnerability databases including the National Vulnerability Database (NVD), GitHub Advisory Database, and vendor-specific advisories. When a new CVE is published, the SCA tool immediately identifies which of your applications are affected, enabling rapid response.

Behavioral Analysis for Malicious Packages

Advanced SCA tools go beyond vulnerability matching to detect indicators of malicious intent. They analyze packages for suspicious behaviors such as:

• Network calls in install scripts — Legitimate packages rarely need to phone home during installation
• File system access outside the package directory — Reading ~/.ssh, ~/.aws, or browser profile directories
• Environment variable exfiltration — Accessing and transmitting process.env contents
• Obfuscated or encoded code — Base64-encoded strings, hex-encoded payloads, or eval() usage
• Newly published packages with high version numbers — A classic dependency confusion indicator
• Packages with no README, no repository, or recently created maintainer accounts

SBOM: Your Software Bill of Materials

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all components in your application, including every direct and transitive dependency, their versions, and their provenance. Think of it as a nutrition label for software — it tells you exactly what ingredients went into your application.

SBOMs are becoming mandatory. The US Executive Order 14028 on Improving the Nation's Cybersecurity requires SBOMs for all software sold to the federal government. The EU Cyber Resilience Act imposes similar requirements for products sold in European markets. Major enterprises are increasingly requiring SBOMs from their software vendors as part of procurement processes.

SBOM Formats

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [{ "license": { "id": "MIT" } }],
      "hashes": [{
        "alg": "SHA-256",
        "content": "a1b2c3d4e5f6..."
      }]
    },
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21"
    }
  ]
}

SBOMs enable rapid incident response during supply chain attacks. When a new malicious package is discovered (like event-stream), organizations with SBOMs can immediately query their inventory to determine which applications are affected, rather than manually searching through hundreds of repositories. This can reduce incident response time from days to minutes.

Building a Supply Chain Defense Strategy

Defending against supply chain attacks requires a multi-layered approach that combines tooling, process, and policy.

1. Lock Your Dependencies

Always commit lock files (package-lock.json, yarn.lock, poetry.lock, Pipfile.lock) to your repository. Lock files pin exact versions and include integrity hashes, ensuring that every build uses precisely the same packages that were tested and approved.

# Use --frozen-lockfile to fail the build if lock file is outdated
npm ci                      # Uses package-lock.json exactly
yarn install --frozen-lockfile
pip install --require-hashes -r requirements.txt

2. Implement SCA in Your CI/CD Pipeline

Run SCA scanning on every pull request and every build. Configure the scanner to fail builds when critical vulnerabilities or malicious package indicators are detected. This ensures that no compromised dependency can reach production without being explicitly reviewed and approved.

3. Scope Private Packages

Use namespace scoping for all internal packages (@company/package-name) and configure your package manager to only resolve scoped packages from your private registry. This eliminates the dependency confusion attack vector entirely.

4. Audit and Minimize Dependencies

Regularly audit your dependency tree and remove packages that are no longer needed. Each dependency is an attack surface. Consider whether you truly need a package or whether the functionality can be implemented with a few lines of code. The infamous left-pad incident showed how a single 11-line dependency can break thousands of applications.

5. Generate and Maintain SBOMs

Automate SBOM generation as part of your build pipeline. Store SBOMs alongside your build artifacts and update them with every release. When a new vulnerability or malicious package is announced, your SBOMs enable immediate impact assessment across your entire application portfolio.

6. Monitor for New Threats Continuously

Supply chain security is not a one-time check. New vulnerabilities are published daily, and previously safe packages can be compromised at any time (as the event-stream incident demonstrated). Continuous monitoring ensures you are alerted when a package you depend on becomes a risk.