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.
npm worm on transactional mail packages: when a mailer library quietly BCCs your payroll emails
A widely used npm package for sending transactional emails (account confirmations, invoices, password resets) was compromised with a one-line backdoor that silently BCCs every outgoing email to an attacker-controlled server. Dozens of HR and payroll SaaS products that email payslips are exposed without knowing it.
GitLab RCE via Oj: a memory-corruption chain hidden in a non-security patch
Two Oj Ruby JSON parser bugs let any authenticated user run commands as `git` on self-managed GitLab <18.10.8 / <18.11.5 / <19.0.2, via crafted Jupyter notebooks. The fix shipped June 10 but was listed under bug fixes, not security. PoC published July 24.
JetBrains TeamCity: a critical auth bypass leading to RCE on your CI/CD server
A critical authentication bypass vulnerability in JetBrains TeamCity On-Premises could be exploited for remote code execution on the CI/CD server — giving attackers access to build pipelines, deployment credentials, and source code. Fix available.
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.