Is Your Vibe Coding Tool Using Deps That Are Vibe Safe?
Vibe coders install whatever the AI recommends, and nothing in that loop stops to check if it's safe. A proposal for Vibe Safe: one open score, one badge, shown at the moment of install.
Millions of people now build software just by describing what they want. Cursor, Bolt, Lovable, v0: you ask, and the tool builds it. That's the promise, and it's a good one.
What it quietly assumes is that the pieces it pulls in are safe to use. Often they aren't, and nothing in the loop checks. Ask for a package and it gets installed. Ask for a browser extension and one gets added. Nothing stops to ask what an experienced engineer asks first: should I trust this, and why?
The attack is ordinary, which is why it works
This isn't sophisticated hacking. It's something smaller and far more common.
A browser extension does something genuinely useful, a syntax highlighter, a tab manager, and also, quietly, reads what's on your screen and sends it somewhere. The author never targets you personally. They just need it popular enough that AI tools start recommending it on their own.
Packages work the same way, with even less friction. To an AI, a library with a clean description and a few hundred stars looks as trustworthy as a real one. Install it, and it can run code that grabs your private keys and ships them off. The trick is old, and it comes in many flavors: a name one typo away from a popular package, or a poisoned update pushed from a hijacked account. What's new is the delivery, bad code riding in through the places we already trust, and the AI tools that read from those places and hand you the result as a recommendation.
The tools exist. They're just not where the decision happens.
None of this is unsolved. There are services that scan packages for exactly this (Socket.dev is one), and the app stores review what they list. They all do real work. The gap is where that work shows up, not whether it's done.
Every one of those checks sits a level below the surface, available to the engineer who already knows to look. The person who most needs it, the one asking an AI to just make it work, never sees it. There's no safety score next to the package the tool just recommended, no mark of review next to the extension. The check and the decision live in different places, and the gap between them is where the risk slips through.
A proposal: one score, at the point of install
If the checking already exists and only its placement is wrong, then what's missing is a single, simple signal that shows up right where you decide.
Call it Vibe Safe: take the checks that already run, roll them into one score, and hand it out as a small badge and a simple lookup any AI tool can call. When a tool suggests a package, the score sits right beside it. Green means someone has already looked. Red means look before you install.
Making it an open standard instead of a product is the part that matters. A product competes, and splits the signal across companies. A standard, if it's open and easy to add, spreads, and spreading is the whole point. Flag a bad package once, and every tool reading the same signal sees it at the same time.
The hard part is coordination, not code
The checking already works. The hard part is getting Cursor, Windsurf, Bolt, and the rest to agree on one signal and show it. That's a coordination problem, not a technical one, and coordination is exactly what open standards are for.
The incentives line up. A trustworthy score is cheap to add and is visible proof a tool takes your safety seriously. The real work is the convening: agreeing on the spec, building one reference version, and landing the first few integrations that make the rest obvious.
Vibe coding isn't a phase. The number of people shipping code they've never read will only grow, and the safety has to meet them where they already are, at the moment they hit install.
This is a research proposal, not a finished product. If you're working on this, or think it's worth turning into a real spec, I'd like to talk.