Would You Trust the Packages Your AI Installed? Supply-Chain Security for Vibe Coding

A true story first: one endpoint, one RCE

One case from October's security digest deserves memorizing by every vibe coder: OpenCode's /global/upgrade endpoint accepted arbitrary package names, letting an attacker fire a cross-origin request from a webpage that installed an npm package with a malicious preinstall script on the victim's machine — the script runs automatically at install time, RCE achieved. The fix was a few lines of logic, but the lesson is universal: dependency installation is the shortest road for supply-chain attacks.

And in the vibe coding workflow, that road has never been wider. In traditional development, you'd read the README, check the stars, skim the issues before installing a package. AI has no such manners — to "make the feature work," it npm installs more generously than you ever would: one CRUD endpoint can pull in 40 packages, half of which you'll never open in your life. Every minute of "evaluation time" you save is interest charged to your future self.

This isn't fear-mongering. In Adversa's October digest, the CodePoisonRAG study showed poisoned code artifacts reaching 0.80–0.93 attack success rates against three code generators; Plugin4Shell proved even "pinned versions" can be bypassed with git-level tricks. In the AI era, dependencies are code, and code is dependencies.

Four ways AI is "generous" with dependencies, each pricier than the last

One: ghost dependencies. AI writes import xxx from 'some-lib', installs it when missing, and the library ends up unused — but stays in package.json. Every ghost dependency is pointless attack-surface expansion you don't even know about.

Two: version drift. AI loves loose ranges like ^1.2.3, or plain latest. The next npm install might pull a poisoned new version. Version drift features heavily in 2026's poisoning incidents, because attackers know nobody diffs a patch-version change.

Three: the script blind spot. npm preinstall/postinstall scripts run at install time with your user privileges — they can read files, hit the network, write cron jobs. AI never warns you "this package ships install scripts," and OpenCode's RCE already demonstrated where that road ends.

Four: the transitive-dependency black hole. You install 1 package; 80 arrive. AI won't inspect the tree, and neither will you. Attackers love hiding in that tiny unmaintained package five layers deep that nobody has touched in three years.

A five-step workflow you can set up tonight

Step 1: pin versions, commit the lockfile. Always use package-lock.json (or pnpm-lock.yaml); always commit it. Give your agent one hard rule: "no latest, no loose ranges, every new dependency must appear in the lockfile." Cheapest step, highest return.

Step 2: make AI "defend" each install. Add a prompt constraint: every new dependency must answer three questions — what does it do (is there a lighter alternative), when was it last updated (a year of silence is a red flag), does it ship install scripts. Can't answer, doesn't get installed. This rule alone blocks roughly half of all ghost dependencies per month.

Step 3: automated auditing in CI. npm audit is the floor; Socket.dev or Snyk is the next level. The point isn't "zero vulnerabilities" (unrealistic) — it's incremental auditing of new dependencies: scan whatever the PR adds, block on critical. Even a vibe project deserves a 5-minute GitHub Action.

Step 4: scheduled package purges. Twenty minutes a month: run npx depcheck to find unused dependencies and delete them; npm ls to spot packages in the tree you no longer recognize. Dependencies rot like code — except code rot is visible and dependency rot isn't.

Step 5: minimal installs in production. Use npm ci --omit=dev in Docker images; devDependencies never ship to production. AI loves installing dev tools (it's convenient!), and history shows plenty of poisoned packages hid in dev dependencies precisely because "it doesn't ship" makes review lazier.

A mental model: the dependency "trust budget"

One framework of mine to close with. Treat each project's trust in third-party code as a budget: a big-vendor package with provenance (build attestation) costs 1; an actively maintained solo project costs 5; a year-stale package with install scripts and deep transitive layers costs 20. A small project gets about 100 — when AI installs the sixth "20-cost" package for you, it's time to stop it.

The beauty of this frame: it translates "security" into language vibe coders understand. Not "don't install," but "do the math before installing." AI gets to be generous; you keep the ledger.

Vibe coding made writing code ten times faster — and supply-chain attacks got exactly as fast. Your agent can install 10 packages a minute; attackers need just one of them. In this arms race, the winner is always the one who took one more look at the lockfile.