The Dependency Model Is Dying

I get asked this a lot. Why is RiskyPlugins focused on browser extensions, IDE plugins, and MCP servers instead of dependency security? Why aren't we competing with Snyk or Socket or JFrog on the npm/pip/cargo side of things?

Because I think the dependency model as we know it is on its way out.

What a dependency actually is

Strip away the tooling and a dependency is just: a set of functions someone else wrote, packaged together, with inputs and outputs. You want a modal in your React app, so you install a library that has hundreds of functions. You use three of them. But all of them get loaded, all of their transitive dependencies get pulled in, and every post-install script in that tree runs on your machine.

That was a reasonable trade-off when writing code was expensive. Developers cost money. Rewriting a modal from scratch for every project is stupid. So you import someone else's work, you inherit their opinions and their security posture, and you move on.

That trade-off is collapsing

In 2026, Claude Code and Codex and the rest of them can read a library's source, understand the implementation, and produce the same functionality inlined in your codebase. Not a copy-paste job. Actually understanding what the code does, adapting it to your patterns, your naming conventions, your architecture.

They're not doing this yet. Not because they can't, but because they've been trained to write code the way developers have always written code. npm install, import, move on. Convention.

But picture this instead: your coding agent needs a modal component. Rather than pulling in a 10,000-function package, it hits an MCP server that indexes open-source implementations. It gets back five reference implementations. It reads them, picks the approach that best fits your codebase, and writes it natively. Your code. Your patterns. No dependency.

You just skipped npm install. No package in your lockfile. No post-install scripts running. No trusting that some developer's npm account didn't get compromised overnight. You read code, made a decision based on code, and moved on.

The math on supply chain risk

If your node_modules has 1,000 dependencies today and you can drop that to 50 by inlining the rest, you've removed 950 developers from your chain of trust. 950 npm accounts that could be compromised. 950 post-install scripts that could be weaponized. 950 people whose MFA could fail.

We've watched this play out. Axios got hit three days ago. A North Korean actor hijacked a maintainer's npm token and shipped a RAT to millions of installs within a 39-minute window. event-stream was a burned-out maintainer who handed publishing rights to a stranger who turned out to be malicious. ua-parser-js was a straight account hijack that deployed cryptominers and credential stealers (CISA put out an advisory for that one). Colors.js was the maintainer himself sabotaging his own packages in protest.

Account compromise, social engineering, maintainer sabotage. Three vectors. The common thread is that the entire model depends on trusting every developer in your dependency tree to stay secure and cooperative forever. That's a bad bet when you have a thousand of them.

SBOMs stop being a joke

Software Bill of Materials. SBOMs. Supposed to be the answer to supply chain transparency. In practice, they're a compliance checkbox that nobody reads because they're absurdly long.

Your React app depends on Meta's React team. Fine. That's a real dependency with a real organization behind it. But it also "depends on" some random developer who wrote a string padding utility three years ago and hasn't logged into npm since. Both show up in your SBOM the same way.

If you buy an electrical panel from Schneider Electric and the bill of materials lists 30 million parts from 3 million suppliers, including someone soldering components in their basement, you'd have questions. That's what a modern JavaScript SBOM looks like.

Cut the dependency count from 1,000 to 50, and suddenly your SBOM is useful. Five vendors. Real organizations. Auditable. The document means something.

A few things need to happen first

I'm not saying this works perfectly today. There are real blockers.

Context windows need to get bigger. A million tokens sounds like a lot until your codebase is ten times larger because you've inlined everything. The agent needs to hold the whole thing in its head to make coherent decisions. Code indexing needs to improve too. When your project grows 10x, you need proper search and navigation so the agent can find what it already wrote. We're getting there but we're not there.

The models also need taste. Right now, AI-generated code works. It's correct. It is not elegant. The code doesn't have an opinion about whether you're optimizing for performance or readability or maintainability. That'll come, but it matters.

So where does that leave dependency scanners?

Snyk, JFrog, Wiz, Socket, they're all doing good work. Scanning npm for malicious packages is a real and current need. But I think they're solving a problem that shrinks year over year as AI-assisted development matures.

I don't think I can out-build those companies on dependency scanning. And more to the point, I don't want to build a product around a paradigm I think is fading.

The new supply chain is plugins

If AI agents stop importing dependencies and start reading code to produce their own implementations, the supply chain risk doesn't disappear. It moves to whatever tools and plugins those agents use to find, evaluate, and integrate code.

MCP servers. IDE extensions. Claude Code plugins. Browser extensions for developer tools. That's the new dependency tree. The code your agent writes depends on the tools your agent trusts.

A compromised MCP server doesn't inject malware into a package. It feeds your agent bad code, or exfiltrates your codebase through the agent's own context, or steers implementation decisions in subtly broken directions. Harder to detect than a malicious npm package. There's no lockfile to audit and no hash to verify.

This is why RiskyPlugins indexes extensions and plugins across Chrome Web Store, Firefox Add-ons, VS Code Marketplace, OpenVSX, and Microsoft 365, with MCP servers next. The plugin layer is where supply chain trust concentrates when traditional dependencies thin out. Every extension gets sandboxed, scanned, correlated with threat intel, and scored.

We're not ignoring npm because we think it's unimportant. We're ignoring it because we think the game is changing, and we'd rather be early to where it's going than late to where it's been.

The bet

I could be wrong. Maybe dependencies stick around for another decade and AI agents keep doing npm install like good little conventional coders. Maybe the context window problem takes longer to solve than I think. Maybe developers resist the shift because they like the ecosystem they know.

But if I'm right, and the dependency count for the average project drops by an order of magnitude in the next three to five years, the security industry will be scrambling to figure out where the risk went. It went to the plugin layer. We'll already be there.