Supply chain: npm, composer, pip — when your dependencies are the attack
> TL;DR: Supply chain attacks via package managers: typosquatting, dependency confusion, maintainer compromise, and how to protect yourself.
Your code is only a fraction of your application
A modern application contains 80 to 95% third-party code via its dependencies. A typical Node.js project installs hundreds of transitive packages. Each one is a potential attack vector. Supply chain attacks target this weak link: rather than attacking your code, the attacker compromises a dependency you willingly install.
Typosquatting
The attacker publishes a package whose name resembles a popular one: lodassh instead of lodash, reqeusts instead of requests. A typo in package.json or requirements.txt installs the malicious package.
Real cases: in 2022, npm packages like ua-parser-jss and colors-2 trapped thousands of developers. In Python, python3-dateutil (with an extra hyphen) contained malicious code.
Protection: always verify the exact package name. Use npm audit, pip-audit, or composer audit to detect suspicious packages.
Dependency confusion
Your organization uses a private registry for internal packages. The attacker publishes a package with the same name on the public registry (npmjs.com, PyPI) with a higher version number. The package manager resolves to the newer public version.
Real case: in 2021, researcher Alex Birsan demonstrated this attack against Apple, Microsoft, and others by publishing packages on npm with the names of their internal packages.
Protection: configure package scoping (@company/package on npm), use namespaces on PyPI, and configure your package manager to prohibit resolution to the public registry for internal packages.
Maintainer compromise
A legitimate maintainer of a popular package is compromised (phishing, credential stuffing) or sells their access. The package is updated with malicious code that executes at installation (postinstall on npm) or at import.
Real cases:
event-stream (2018): a new maintainer added a malicious dependency targeting Bitcoin walletsxz-utils (2024): a patient contributor earned the maintainer's trust over two years before introducing a backdoor into the compression library used by SSHua-parser-js (2021): the maintainer's npm account was compromised, the package (7M downloads/week) was updated with a cryptominerInstallation scripts
npm's preinstall and postinstall scripts run with the same permissions as the user running npm install. A malicious package can exfiltrate environment variables (CI/CD tokens, API keys), modify other project files, or install backdoors.
Protection: use --ignore-scripts for untrusted installations. Configure .npmrc with ignore-scripts=true and only enable scripts for packages that genuinely need them.
Lockfiles and integrity
The package-lock.json, composer.lock, or poetry.lock ensures installation reproducibility. But if the lockfile is modified (by a malicious PR or a registry compromise), integrity is lost.
Protection:
npm ci (not npm install) in CI/CD to strictly follow the lockfileintegrity in package-lock.json)Defense in depth strategy
npm audit, pip-audit, composer audit in your CI/CDAt CleanIssue, we analyze the dependency tree of your applications during our audits. Request your audit call to evaluate your supply chain attack exposure.
Key Takeaways
Building HR, payroll, or recruiting software? CleanIssue performs security audits for HR SaaS in real-world conditions, no source code access needed. For a first read of your exposure, start with an external review of your application.
Related articles
Three adjacent analyses to keep exploring the same attack surface.
Supply chain attacks on payroll software: how they work and how to protect yourself
Supply chain attacks no longer target only large corporations. Payroll software vendors are prime targets. Here's a breakdown.
XSS explained: reflected, stored, DOM-based — how to protect yourself
The three types of Cross-Site Scripting explained with concrete examples, common attack vectors, and defenses to implement.
Next.js CVE-2026-44578: an SSRF via WebSocket on self-hosted instances
An SSRF flaw (CVSS 8.6) in Next.js's built-in Node.js server lets an unauthenticated attacker proxy requests to your internal services. Vercel is unaffected; self-hosting is. Fix: 15.5.16 / 16.2.5.
Sources
Editorial analysis based on official vendor, project, and regulator documentation.
Related services
If this topic maps to a real risk in your stack, these are the most relevant CleanIssue audits.