In February 2021, security researcher Alex Birsan proved a simple point: he could get code executed inside the networks of Apple, Microsoft, PayPal, Netflix, Uber, Shopify, and 29 other companies just by publishing packages with the right names to public registries. His total cost was a handful of free npm and PyPI accounts and a few afternoons of scripting. His total payout was over $130,000 in bug bounties — and that was the defensive researcher's payout. For an attacker running the same playbook without disclosing it, the payout is stolen credentials, crypto wallets, and CI/CD access. That asymmetry — near-zero cost to publish, uncapped upside if it lands — is the entire business model behind fake packages. Sonatype's 2023 State of the Software Supply Chain report counted 245,032 malicious packages identified that year alone, more than every prior year combined. This post breaks down why the math favors the attacker so heavily, and what actually changes it.
Why is publishing a malicious package essentially free?
Because neither npm nor PyPI charges money, requires identity verification, or reviews code before a package goes live. Anyone can create an account with a throwaway email and npm publish a package within minutes — no KYC, no code audit, no waiting period. npm now hosts over 3.1 million packages and PyPI over 550,000 projects, and both registries were built for frictionless publishing, not gatekeeping. That design choice is what made open source ecosystems grow so fast, and it's also what makes them cheap to abuse. An attacker's marginal cost per package is close to zero: register a name, upload a script, done. Compare that to the cost of, say, compromising a bank's network directly — social engineering, exploit development, evading EDR. Publishing a package that a developer will voluntarily npm install skips nearly all of that. The registry itself does the delivery work for you.
What's the actual payout when a fake package succeeds?
It ranges from a few hundred dollars in stolen crypto to full enterprise network access, and attackers increasingly automate for the high end. In October 2021, a compromised version of ua-parser-js — a library with roughly 7 million weekly downloads — was modified to install a cryptominer and a password stealer on machines that ran npm install. In December 2022, a dependency-confusion attack against PyTorch's nightly builds published a malicious torchtriton package to PyPI that exfiltrated SSH keys, environment variables, and system data from anyone who installed the official nightly package, because PyTorch's internal index name collided with a public one. Once inside, attackers don't need every install to pay off — they need one developer laptop with cloud credentials, or one CI runner with a signing key. A single compromised pipeline can be worth far more than the thousand failed installs it took to get there.
Why do typosquats and dependency confusion scale so well?
Because both attacks are trivially automatable and the registries impose no rate limit on how many variants you can register. A popular package like requests has hundreds of plausible typo variants — character swaps, omitted letters, homoglyphs, added hyphens, suffixes like -python or -js. Registering all of them costs nothing, so attackers script bulk publication and let probability do the work: out of a thousand developers who mistype a package name, only a few need to fall for it. Dependency confusion works the same way in reverse — instead of guessing typos, the attacker guesses internal package names (often leaked in job postings, GitHub repos, or error messages) and publishes a same-named package publicly with a higher version number, betting that a misconfigured build will prefer the public copy. Phylum and Checkmarx have both documented campaigns where a single automated account published hundreds of packages in a single day, cycling through name permutations faster than any manual review process could keep up.
How long do fake packages survive before anyone notices?
Often days, sometimes months, because most consumers don't watch a package after they first install it. The node-ipc incident in March 2022 is a useful case: the maintainer of a legitimate package with roughly 1 million weekly downloads pushed an update that wiped files on machines with Russian or Belarusian IP addresses. It shipped through the normal update channel and reached downstream projects before the community caught on. Similarly, in January 2022 the maintainer of colors.js (around 20 million weekly downloads) and faker.js deliberately corrupted his own packages with an infinite loop, breaking thousands of dependent builds overnight — a self-inflicted supply chain incident that still took hours to trace back to the root cause across affected organizations. Detection generally comes from one of three places: automated scanners run by security vendors, a developer noticing broken behavior, or a researcher stumbling onto it. None of those happen at publish time by default, which is exactly the window attackers are pricing in.
Why is the legal and reputational risk so low for attackers?
Because registries are global, accounts are anonymous, and takedown doesn't equal attribution. An attacker publishing from a burner email through a VPN faces almost no realistic path to prosecution even after a package is caught and removed — by the time anyone investigates, the account is gone and a new one is trivial to create. Some campaigns even manufacture false trust signals to speed up the attack: gray-market services sell fake GitHub stars and inflated download counts for a few dollars per hundred, letting a two-day-old package look established enough that a developer skips due diligence. Combine low probability of identification with low cost of a burned account, and the expected penalty for getting caught rounds to zero. That's the missing variable in most engineering teams' risk models — they think about the cost of a breach, not the cost structure of the thing that caused it.
How Safeguard Helps
The reason fake package economics favor attackers is that most of the cost sits on the defender's side after the fact — incident response, credential rotation, forensic review — while the attacker's cost stays flat regardless of outcome. Safeguard shifts that balance back by raising the attacker's cost before installation, not after compromise. Safeguard continuously scans registry activity for the same signals researchers use manually — newly published packages with suspicious install scripts, name similarity to high-traffic packages, sudden maintainer or ownership changes, and version jumps that resemble dependency-confusion patterns — and flags them before they reach a developer's package.json or a CI pipeline's build step. For teams with internal package names, Safeguard helps identify and close the dependency-confusion gap by mapping private package names against public registries so a same-named public upload can't silently win resolution. And because typosquat campaigns rely on volume, Safeguard's provenance and integrity checks make it economically unattractive to keep trying: when every install is verified against known-good publishers and behavioral baselines, publishing a thousand throwaway variants stops being a numbers game the attacker can win. The goal isn't to catch every fake package after the fact — it's to make the attack expensive enough that the math from Birsan's original demonstration stops working in the attacker's favor.