Dependencies are the long tail of your attack surface. The security industry keeps selling you a longer telescope. What you need is a shorter tail.

01 Flip the axis

Your application has 1,200 dependencies. You chose maybe forty of them. The other 1,160 were dragged in by the forty you chose, and by the dependencies of those dependencies, and by the dependencies of those. You have never read their code. You do not know who maintains them. In some cases, nobody does.

Each of those 1,160 packages is individually negligible. Nobody loses sleep over a three-line utility six levels deep in a transitive graph. But an attacker only needs one of them. One burned-out maintainer who hands over the keys to a stranger. One post-install script that phones home. One moment where the probability of compromise across the entire graph tips from unlikely to inevitable.

This is the long tail — the same shape Chris Anderson described in 2004 when he argued that the aggregate value of obscure products exceeds the value of the blockbusters. He was talking about Amazon and Netflix. The same curve applies to software risk. Most security effort concentrates on the head: your application code, the operating system, the major framework. But the actual attack surface — the place where breaches happen — is dominated by the tail. Hundreds of packages nobody is watching, each one too small to matter, together too numerous to secure.

Anderson's long tail was enabled by near-zero distribution costs. Digital shelves are infinite. The dependency long tail was enabled by the same force: near-zero integration costs. npm install is frictionless. go get is frictionless. The cost of adding a dependency is zero at the point of decision. The security cost accumulates silently, invisibly, until it detonates. A classic externality — the bill arrives later, and someone else pays it.

The industry's entire answer to this has been additive: buy something that watches the tail. Scanners, dashboards, software bills of materials, monitoring agents. This article ends up somewhere else, at a position I will call reductive security — and the case for it takes some building, because the additive model is not stupid and the alternative is not "write everything yourself." Worth knowing that is where this goes before we look at what the tail has cost people who were watching it carefully.

02 The tail is where the attacks are

In September 2018, a user called right9ctrl sent an email to Dominic Tarr, the original author of event-stream, a package with two million weekly downloads. Tarr had not touched the code in years. He was tired. He handed over full publishing rights to a stranger on the internet.

Right9ctrl added a single dependency — flatmap-stream — containing an encrypted payload that specifically targeted the Copay Bitcoin wallet. The code was surgically precise: it only activated inside Copay's build environment, making it invisible to anyone else who installed the package. It ran undetected for two and a half months and was downloaded around eight million times in that window.⁸ Event-stream sat deep in the dependency trees of thousands of other projects, including Vue CLI, VS Code and nodemon.⁸

No phishing. No credential theft. No zero-day exploit. The attacker identified a fatigued maintainer in the tail and was handed the keys voluntarily. The long tail's defining feature — that nobody watches the individual items — was the entire attack vector.

That was 2018. The trajectory since has been vertical.

Event-stream was one attacker, one package, one target. Shai-Hulud weaponised the graph itself. IndonesianFoods industrialised the creation of malicious surface area. Axios confirmed that nation-states treat your node_modules folder as an attack vector. The escalation is not linear. It is compounding.

03 The numbers

The narrative is supported by data that has gone from concerning to absurd. Sonatype has catalogued over 1.233 million malicious open source packages since it began counting in 2019.⁶ More than 454,600 of those were published in 2025 alone — across npm, PyPI, Maven Central, NuGet and Hugging Face — with nearly 89% of the year's total logged in the fourth quarter. The curve is not steepening gradually. It is bending.

Black Duck's 2025 OSSRA report, drawn from audits of 965 commercial codebases, found the average project now carries over 1,200 dependencies — a 30% increase year-on-year — and that 64% of the open source components it found were transitive rather than directly chosen.⁷ Most of what you ship is other people's work, pulled in by other people's decisions, maintained by other people's volunteers.

And the tail is not just unwatched. It is unmaintained — the overwhelming majority of vulnerable components in circulation have a fixed version already published, sitting unused because nobody upgraded.

OWASP ranked Software Supply Chain Failures as the third most critical web application security risk in its 2025 Top 10, and half of the community survey respondents ranked it first.² The probability of any single package in a graph of 1,200 nodes being compromised is low. The probability of none of them being compromised is lower.

04 AI steepens the curve

The industry narrative is that artificial intelligence will save defenders. The data from 2025 and 2026 says it is saving attackers faster.

This matters to the long tail argument specifically, not just to cybersecurity in general. AI does not change the shape of the dependency curve. It steepens it. It makes the tail longer on the attack side and no shorter on the defence side. Three capabilities explain why.

AI scales the creation of malicious surface area. Sonatype's own count makes the point without needing a vendor's threat-research headline: roughly 89% of 2025's malicious packages were published in the final quarter alone.⁶ That is not a campaign. That is a production line, and no human-paced operation produces that curve. The barrier to manufacturing the tail has collapsed.

AI enables precision social engineering against maintainers. A controlled field experiment presented at USENIX Security 2026, run across 7,741 participants, found that personalised AI-generated phishing achieved 2.4 times the click rate of generic phishing, at a cost of roughly three cents per message — and the authors call that a conservative estimate, because they used simple locally-run models against participants who had already had security training.¹¹ Compare the economics. Event-stream in 2018 required a human to build trust with Dominic Tarr over a period of weeks. The Axios compromise in March 2026 needed a maintainer account and nothing else. Personalised, convincing, targeted social engineering now costs less than a stamp, and every solo maintainer in the tail has a public email address.

AI powers autonomous propagation. Shai-Hulud's worm behaviour — compromising a package, finding tokens, publishing malicious versions of other packages — is exactly the kind of sequential, adaptive task that agentic AI excels at. The next Shai-Hulud will not need human orchestration at all.

The asymmetry is structural, not temporary. A study led from Johannes Kepler University Linz ran autonomous AI agents across 23 attack/defence CTF battlegrounds.¹ Defensive agents achieved 54.3% unconstrained patching success against 28.3% offensive initial access — an apparent defender advantage. Tighten the definition of success and it evaporates: 23.9% when the patch must also preserve availability, and 15.2% when it must additionally keep the attacker out. The authors are blunt about what that means — the 39.1-point gap between basic patching and complete defence "indicates that apparent defensive superiority may result from unrealistic assessment criteria." Once defence is scored operationally, no statistically significant advantage remains. The World Economic Forum's Global Cybersecurity Outlook 2026 — 804 respondents across 92 countries — found 87% identifying AI-related vulnerabilities as the fastest-growing cyber risk of 2025.⁹

Defence, meanwhile, has mostly bolted a chatbot onto the SOC. The gap is not that defenders lack AI. It is that attackers are using it to manufacture surface area faster than defenders can read it.

AI does not close the long tail. It makes the tail grow faster than any scanner can read it.

05 The additive trap

Every solution the security industry has offered to the supply chain problem is additive. Add Snyk. Add Dependabot. Add SBOM tooling. Add SCA scanning. Add Sonatype Repository Firewall. Add Trivy to your CI pipeline. Each of these is itself software, with its own dependencies, its own attack surface, its own maintainer accounts, its own update cycle.

The response to the long tail has been to make the tail longer.

This is not a failure of any particular vendor. It is a structural failure of the additive model. When your defence against compromised dependencies is itself a dependency, you have added a node to the graph you are trying to shrink. When your scanner has transitive dependencies of its own — and it does — each of those is another package that can be poisoned, another maintainer who can be phished, another post-install script that can execute in your build environment.

The incentives make this worse. The security industry is a market. Markets grow by selling product. Every vendor's revenue model depends on your problem being large enough, persistent enough, and frightening enough to justify a subscription. Nobody in that market has a commercial incentive to tell you to use fewer dependencies. The advice that would most reduce your attack surface — write less code, import less code, depend on fewer strangers — is advice that shrinks the addressable market for the people selling you protection. So instead you get dashboards. You get scanners. You get more software to protect you from software.

Even Chainguard — whose entire brand is built on minimal container images and attack surface reduction — put it well in their own 2026 analysis: "the smart move is to eliminate entire categories of vulnerability, freeing up teams to focus on the remaining areas." Correct. Now note what they are selling you: a product. A product you add to your pipeline to make your containers smaller. The company preaching reduction is running an additive business model. Their own words are a better argument against the industry's approach than anything a critic could write. When even the vendors who understand the problem can only monetise it by giving you another tool to install, the structural incentive is laid bare.

The additive model assumes the graph is a given and the solution is visibility. More monitoring. More scanning. More tools. But visibility is not control, and monitoring the tail does not shorten it. You cannot telescope your way out of a problem caused by the length of the thing you are looking at.

06 The case for dependencies

Before arguing for reduction, it is honest to argue the other side. Dependencies exist for good reasons, and a blanket rejection of them is not serious engineering — it is nostalgia dressed as security.

Cryptography is the obvious case. Rolling your own TLS implementation is not reductive security. It is recklessness. The Go standard library ships crypto/tls and crypto/aes precisely because these are problems that should be solved once, correctly, by specialists, and reused by everyone else. The same principle applies to image decoding, compression, and any domain where subtle implementation errors create exploitable vulnerabilities. Using a well-audited, widely-deployed library for these tasks is strictly safer than writing your own.

There is also a workforce reality. Not every team has the depth to reimplement what a mature library provides. A four-person startup building a SaaS product cannot write their own HTTP framework from scratch and still ship. Dependencies let small teams punch above their weight. That leverage is real and valuable.

And even the standard library argument has a crack in it. Go's stdlib is itself a massive dependency maintained by a single organisation — Google. If Google's build infrastructure were compromised, the blast radius would dwarf any npm incident. The stdlib is not zero dependencies. It is one very large, very trusted dependency. The risk is concentrated rather than distributed, which is a different profile, not the absence of risk.

The distinction is between dependencies as a considered engineering decision and dependencies as accumulated habit. Between importing a cryptographic library because the domain demands it and importing a left-pad utility because npm install is easier than writing four lines of code. Between a dependency tree you can draw on a whiteboard and one that requires specialised tooling to visualise.

Dependencies are not the enemy. Uncontrolled dependencies are the enemy. The long tail is not built from the thirty packages you chose carefully. It is built from the 1,170 that came along for the ride.

So the question is not whether to use dependencies. It is how many, chosen how carefully, controlled how tightly. And that question has a name.

07 Reductive security

The security industry has spent two decades selling additive solutions to a problem caused by addition. Reductive security is the counter-position: the deliberate, architectural elimination of attack surface rather than the addition of monitoring for it.

The foundational axiom is simple. All code carries risk. Every line is a liability. Every dependency is a bet on the honesty, competence, and continued attention of a stranger. Every tool you add to watch that bet is another bet. Reductive security asks: what if we placed fewer bets instead of hiring more people to watch them?

Consider the difference in practice. A typical Go web service — HTTP API, database, structured logging — has three or four dependencies total. The Go standard library ships HTTP servers, TLS, JSON parsing, HTML templating, testing and profiling out of the box, and a driver-agnostic SQL interface in database/sql that you pair with one driver. A service built on the stdlib and that driver has a dependency graph you can hold in your head. You can read every line of third-party code in your project in an afternoon. No packages to install at build time. No maintainer accounts to phish. No post-install scripts to execute. No transitive graph to traverse. The attack surface is the runtime and your code. Two things. Both auditable. The binary that comes out the other end is a single static file. You deploy it. It runs. There is no supply chain to attack at deployment time, no dependency resolution in production, no node_modules folder for a worm to crawl through. What you built is what you run.

Now place that next to the alternatives. Django — one of the most mature and security-conscious web frameworks in existence — ships with three direct dependencies: asgiref, sqlparse, and tzdata on Windows. A typical Go web service has three or four. The average JavaScript project on GitHub pulls in 683 transitive dependencies from roughly ten direct ones — and that figure is from 2020.⁴

Notice that Django and the Go service land in the same place. That is the more useful observation, because it rules out the lazy reading of this argument. This is not Go being virtuous and Python being profligate — a batteries-included Python framework with two decades of production use arrives at the same number as a Go service written against the stdlib. Lean dependency graphs are achievable in any ecosystem. They are a function of culture and taste, not of language.

Which leaves one outlier, and it is an order of magnitude away from everything else. That is not a spectrum of capability — Django and Express and a Go stdlib service can all build the same product. It is a spectrum of philosophy. One end treats dependencies as free. The other treats them as debt that accrues interest. The distance between three dependencies and 683 is not a technical decision. It is the long tail, measured in packages.

The word "reductive" does real work here. It positions against the industry assumption that security is always additive — that the answer to a growing attack surface is more scanning, more monitoring, more tools. The reductive position is that every scanner you add is code you must trust, every monitoring agent is a process that can be subverted, and every SBOM generator is itself a dependency in your pipeline. The only tool that cannot be compromised is one you did not install.

08 What this looks like in practice

Reductive security is a design philosophy, but it has to survive contact with a codebase. These are the decisions where it becomes real.

Before introducing a dependency, ask what it brings and what it costs. Assess its maintainer count, commit frequency, and transitive tree. If you need one function from a library that brings sixty packages with it, write the function. Six lines of code you understand will always be more secure than six hundred lines you have never read.

Pin exact versions and commit your lockfile. Semantic versioning is a social contract, not a security guarantee. A caret range like ^3.3.5 is what allowed event-stream's malicious 3.3.6 to silently propagate to every project that depended on it. Treat npm install in CI as a code smell — use npm ci, which fails if the lockfile does not match. Better yet, vendor your dependencies: copy the source into your repository, audit it, and remove the live fetch from your build entirely. You trade convenience for control. In a regulated environment, that trade is not even close.

Disable post-install scripts by default. Many supply chain attacks — including both Shai-Hulud campaigns — execute during the install phase, before your application runs a single line of its own code. Allowlist only the packages that genuinely need lifecycle hooks. Everything else runs silent.

Finally, treat dependency count as a metric. Track it. Report it. Set a ceiling. When someone proposes adding a package, the question is not "does this save time?" It is "is the time saved worth the perpetual security exposure?" The answer is sometimes yes. It should never be unasked.