52,000 packages passed every security check. Chainguard blocked them anyway.

Open-source packages are supposed to fail security scans if they're dangerous. Chainguard has found 52,000 that don't — and says that's the whole problem.

The company launched a new source code scanner this week that catches what it's calling "greyware": packages that pass every existing scan on the market, do exactly what they advertise, and still export your credentials, harvest your API keys, or establish a permanent backdoor to a third-party server.

"Frank in finance is not a coder. He's an FP&A guy. And so along comes a solution that can say, hey, you can vibe code stuff into existence — but don't just grab random stuff off the internet that could come from anywhere or be manipulated by bad actors." — Quincy Castro, Chainguard CISO

What actually changed

• New scanner, new category. Traditional malware hides what it does. Greyware doesn't — it just buries the harmful parts in plain sight. Chainguard is now scanning for both.
• Scale: 100,000+ packages scanned per day. 52,000 already blocked as malware or greyware.
• Live examples still on npm: Packages like chrome-tools and @robinpath/cloud-cli openly export modules for harvesting Chrome passwords, cookies, and credit card data, or establish permanent backdoors to third-party servers. All five flagged examples passed npm's standard seven-day trust cooldown. All are still downloadable.
• Pre-emptive, not reactive: The scanner evaluates packages before they're added to Chainguard Libraries — not when a developer requests them — eliminating the exposure window where cached malicious packages can slip through before detection fires.

Why vibe coding makes this a structural problem

Greyware isn't new. What's new is that agentic development has removed the human who might have caught it.

Manual dependency review was already losing before AI coding tools arrived. Now you have non-technical users spinning up production workflows via natural language, with AI agents automatically pulling in packages — and no SRE standing between the developer and the damage.

The threat model is specific: a knowledge worker vibe codes a workflow automation tool, their agent pulls in a package that requires access tokens to function, and those tokens get quietly exported to a remote command-and-control server. The package passed the scan. It did exactly what it said it would do. Nobody notices until something downstream goes wrong.

The lesson

Security scanning has always optimised for finding things that hide. Greyware doesn't hide. It tells you exactly what it does and counts on you not reading carefully enough to notice the bad parts.

Supply chain security has been dominated by typosquatting, dependency confusion, and compromised maintainer accounts — threats where something is concealed. This is a different category: the package is transparent about its behaviour, and honest behaviour can still be harmful.

What to do

• Using Chainguard Libraries for npm? You're already covered. The scanner is live and running.
• Not using Chainguard? Audit recent dependency installs for anything requesting access tokens, network permissions, or credential access beyond its stated purpose.
• Shipping agentic workflows? Treat every auto-installed dependency as untrusted. Your AI agent doesn't read READMEs carefully. That's now your risk surface.
• Security team? The 52,000-package data point is a useful forcing function for getting greyware onto your threat model before it ends up on your incident report.

Coverage is currently npm/JavaScript only — more ecosystems are coming in the next few weeks.

Source: The New Stack — Chainguard's greyware scanner launch

✏️ Drafted with KewBot (AI), edited and approved by Drew.