Supply Chain Attacks in Open Source: The Growing Threat to Software Security

The Attack Surface We Built

Modern software doesn't get built — it gets assembled. A typical Node.js application pulls in 500-1,500 transitive dependencies. A Python ML project can easily depend on 200+ packages. Each dependency is a link in a supply chain, and each link is a potential entry point for an attacker.

In 2024, the XZ Utils backdoor demonstrated just how sophisticated these attacks can become. A patient attacker spent two years building trust as a maintainer, gradually introduced obfuscated malicious code into the build process, and nearly compromised SSH authentication on every major Linux distribution. It was caught by accident — an engineer noticed a 500ms latency increase in SSH connections.

How Supply Chain Attacks Work

1. Typosquatting

Attackers publish packages with names similar to popular ones: lodahs instead of lodash, reqeusts instead of requests. When a developer makes a typo in their install command, they get the malicious package instead. These packages often include the legitimate code plus a payload that exfiltrates environment variables (which frequently contain API keys and database credentials).

2. Dependency Confusion

Organizations often use internal package registries alongside public ones. If an internal package named company-utils exists on the private registry, an attacker can publish a company-utils package to the public npm registry with a higher version number. Many package managers will prefer the public package with the higher version, pulling in malicious code.

3. Maintainer Compromise

Attackers gain access to a legitimate maintainer's account through credential theft, social engineering, or — as with XZ Utils — by becoming a trusted maintainer themselves. Once they have publish access, they can push a malicious version to millions of downstream consumers.

4. Build Process Manipulation

Attacks that don't modify the source code but alter the build process. Compromised CI/CD pipelines, malicious build scripts, or tampered build tools can inject code that doesn't appear in any code review.

Real-World Impact

• XZ Utils (2024): Backdoor in a compression library nearly compromised OpenSSH on major Linux distributions. Detected by chance.
• event-stream (2018): Popular npm package (2M weekly downloads) was compromised to steal Bitcoin wallet credentials.
• ua-parser-js (2021): npm package with 7M weekly downloads was hijacked to distribute cryptominers.
• PyPI malware campaigns (2023-2025): Hundreds of typosquatting packages targeting Python developers, collectively downloaded millions of times.

Defensive Practices

For Individual Developers

• Use lockfiles religiously. package-lock.json, poetry.lock, Cargo.lock — these pin exact versions and integrity hashes. Commit them. Review changes to them in PRs.
• Verify package names carefully. Double-check the package name before installing. Look at download counts and repository links.
• Enable 2FA on package registries. If you maintain packages, protect your account. Enable 2FA on npm, PyPI, and GitHub.

For Engineering Teams

• Run dependency audits in CI. npm audit, pip audit, cargo audit — automate these as CI checks that block merges on critical vulnerabilities.
• Use a private registry proxy. Tools like Artifactory or Verdaccio act as a proxy between your team and the public registry, allowing you to allowlist approved packages.
• Monitor for new dependencies. Alert when a PR adds a new dependency. Review it with the same scrutiny as application code.
• Pin to exact versions. Use exact versions ("lodash": "4.17.21") rather than ranges ("^4.17.0") for production dependencies.
• Use Sigstore/cosign for verifying package provenance where available.

For the Ecosystem

The open source community is responding with initiatives like npm's package provenance (linking published packages to their source repository and build), Sigstore's keyless signing, and SLSA (Supply-chain Levels for Software Artifacts) framework. Adopting these standards as they mature is important for the entire ecosystem's security.

The Uncomfortable Truth

Perfect supply chain security is impossible when you depend on code written by strangers on the internet. The goal isn't zero risk — it's reducing risk to manageable levels through defense in depth. Lock your dependencies, monitor for anomalies, and build the organizational muscle to respond quickly when something gets through.