menu

I built a free IDE extension to catch malicious npm packages before they wreck your project

●1 ●3 ●12
calendar_today • schedule1 min read

Supply-chain attacks via npm are up year-over-year — packages like event-stream,
the Lazarus group drops, and AI-hallucinated typosquats keep landing in real codebases.
I got tired of finding out after the fact, so I built NPM Safety Guard.

What it does

It scans your package.json and lockfiles right inside your editor — no separate CLI step.

Here's what it currently catches across 22 detection layers:

  • Known malicious packages — DPRK RAT drops, Lazarus-linked packages, event-stream clones
  • CVEs — via OSV.dev, cached locally (free, no API key needed)
  • Typosquatting & homoglyph attacks — catches lodahs, reàct, and AI-hallucinated package names
  • Install script hooks — flags preinstall/postinstall before you run them
  • Deep tarball AST scan — detects obfuscation, eval, and payload patterns in the actual source
  • Dependency confusion — scoped packages planted on public npm to hijack private installs
  • Exposed secrets — API keys, tokens, private keys accidentally left in .env, .npmrc, .pem
  • MCP server config scanner — catches typosquatted or malicious MCP transport configs
  • Supply chain graph — interactive force-directed graph with risk overlay from your lockfile
  • OSSF Scorecard + Socket.dev score — security hygiene at a glance

Where to get it

All free. No account required for the core layers. MIT licensed on the VS Code side.

Under the hood

The VS Code extension is TypeScript. The JetBrains plugin is Kotlin. They share the same
detection signatures bundled at build time — no cloud dependency for the core scan.

CVE lookups hit OSV.dev with a 24-hour local cache so you're not waiting on a network
call every keystroke.

Have you been burned by a supply-chain attack before? Or do you have a detection layer
you wish existed? Drop it in the comments — I'm actively adding new signatures.

13 Comments

•

This is actually a pretty useful idea. npm supply-chain stuff is getting sketchy enough that catching bad packages earlier makes a lot of sense.How are you handling false positives so it doesn’t get noisy?

2 votes
•

@[peponder] Thanks! Yeah, supply-chain attacks have been ramping up a lot — it felt like a gap worth closing right in the IDE.

For false positives, the extension uses a multi-signal approach rather than flagging on any single heuristic. It cross-references known malicious package databases (like the OSS Malicious Packages dataset), checks for typosquatting patterns against popular packages, and looks at publish metadata anomalies (e.g. brand-new package with no repo, sudden ownership transfer, obfuscated install scripts).

The idea is that a single yellow flag doesn't block you — it needs a combination of signals to raise a warning. You also get context on why something was flagged, so you can make the call yourself rather than just getting a blanket block.

Still iterating on the threshold tuning. If you try it and hit a noisy case, I'd genuinely love the feedback — it helps calibrate the scoring.

1
•

I think NPM newer versions will be adressing the last security issues we witnessed (especially the postinstall part ...).

3 votes
•

@[Med Marrouchi] That's a fair point — npm has been making real strides, and tightening postinstall restrictions is a step in the right direction.

That said, I think there's still a gap the extension helps fill: npm's security improvements happen at install time, but by then the package is already being pulled into your project. The goal here is to catch suspicious packages before you even run npm install — right when you're typing the package name in your editor.

It's less about replacing what npm is doing and more about shifting the detection earlier in the workflow. Supply-chain attacks also keep evolving (typosquatting, dependency confusion, malicious updates to legitimate packages) in ways that versioned npm fixes can't always anticipate fast enough.

So hopefully they complement each other rather than overlap. Would love to hear your thoughts if you see specific areas where the extension could better adapt to what npm is already handling!

2
•

@[jomy_nn] Totally agree. Another issue I find is that now even IDE extensions are source of vulnerabilities. Take for example the last github incidents where the source of vulnerability was indeed a vscode extension.

2
•

@[Med Marrouchi] You're raising a really valid point — and honestly, it's something I thought hard about while building this.

The irony isn't lost on me: an extension warning you about malicious packages could itself become an attack surface. The GitHub/VSCode incidents you're referencing are a perfect example of why trust in tooling can't be assumed.

A few things I've tried to do to keep NPM Safety Guard trustworthy:

  • No remote code execution — the extension doesn't run scripts or shell commands
  • Minimal permissions — it only reads your package.json, no filesystem or network access beyond the package lookup API
  • Open source — the code is fully auditable on GitHub so anyone can verify what it's actually doing

But you're absolutely right that users should scrutinize any extension they install, including this one. Trust but verify. 🙂

2
•

Interesting, many packages have recently shown vulnerabilities. That could really help us

3 votes
•

@[Josaphatstar] Exactly! The number of compromised packages has been climbing steadily — and a lot of them slip through because developers trust the ecosystem by default. That's the gap this extension tries to close: flagging suspicious packages right in the editor before they ever touch your project. Hope it saves you from a headache or two! 😄

2
•

This is honestly pretty clean, love the concept as well, since the talk of the npm worm came out a few weeks ago.

2 votes
•

@[immanuel-gabriel] Thanks so much, really appreciate it! 🙏

Yeah, the npm worm discussion was honestly a big wake-up call for a lot of developers — it showed just how fast a malicious package can propagate through the ecosystem once it gets a foothold. That's exactly the kind of scenario this extension is designed to help with: catching the suspicious package before it lands in your project rather than scrambling after the fact.

Glad the timing feels relevant — would love to hear any feedback if you give it a spin!

0
•

Catching issues before npm install feels like the right place in the workflow. Security tools usually tell us what went wrong after the damage is done. Curious which detection layer has produced the most surprising findings so far?

2 votes
•

@[buildbasekit] Honestly, the AI Config Guard layer (added in v1.15.0) was the most eye-opening. It was a direct response to the Nx Console incident where packages were stealing Claude Code credentials and 1Password sessions from developer machines. Nobody expected supply chain attacks to go after your AI assistant config. The dependency-confusion layer is a close second — the number of suspiciously named public packages with zero download history is unsettling once you start looking.

2
•

@[jomy_nn] The AI config angle is definitely not where most developers expect supply-chain attacks to show up.

Feels similar to how attackers always seem to target the weakest link in the workflow rather than the part everyone is watching. I'll have to read up on the Nx incident. Thanks for sharing that example.

1
🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.
Join CoderLegion

More Posts

How I Built a React Portfolio in 7 Days That Landed ₹1.2L in Freelance Work

Dharanidharan - Feb 9

Comparison: Universal Import vs. Plaid/Yodlee

Pocket Portfolio - Mar 12

I’m a Senior Dev and I’ve Forgotten How to Think Without a Prompt

Karol Modelskiverified - Mar 19

5 Web Dev Pitfalls That Are Silently Killing Your Projects (With Real Fixes)

Dharanidharan - Mar 3

MCP Is the USB-C of AI. So Why Are You Plugging Everything In?

Ken W. Algerverified - Jun 10
chevron_left
jomynn
327 Points • 16 Badges
Thailand • t.co/KtJ4M9krce
2Posts
7Comments
jomynn

More From jomy_nn

NPM Safety Guard — All 23 Security Layers Explained

Related Jobs

View all jobs →

Commenters (This Week)

5 comments
1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!