DEV Community: jomynn

🛡️ NPM Safety Guard — All 23 Security Layers Explained

jomynn — Mon, 29 Jun 2026 06:20:23 +0000

Every npm project is one malicious package away from a supply-chain breach. NPM Safety Guard catches threats that npm audit completely misses — from DPRK backdoors and typosquatted packages, to exposed API keys and AI credential theft hidden inside your node_modules.

This video walks through all 23 detection layers, one by one, showing exactly what each layer catches and how it protects your project in real time.
🛡️ Intro
NPM Safety Guard is the most comprehensive npm security scanner for developers. It ships as a VS Code extension (also works in Cursor and Windsurf) and a JetBrains plugin (WebStorm, IntelliJ IDEA, and all IntelliJ-based IDEs). It runs silently in the background and alerts you to supply-chain threats, malware, CVEs, and credential leaks — before they can cause damage.

Layer 1 — Known Malicious Packages
Checks every package in your package.json against a bundled database of documented supply-chain attacks, including DPRK/Lazarus Group backdoors, the infamous event-stream compromise, and dozens of other confirmed malicious packages. The database is also synced against a live remote feed so newly discovered threats are caught even before you update the extension.

Layer 2 — CVE Vulnerabilities
Queries the Google OSV.dev API for known CVEs across all your direct dependencies. No API key needed — it is completely free. Results are cached for 24 hours to minimize network calls. CVSS scores are mapped to severity levels (Critical, High, Medium, Low) so you always know exactly how serious each vulnerability is and which version fixes it.

Layer 3 — Install Script Hooks
Flags packages that declare preinstall, postinstall, install, or prepare npm scripts. These hooks run automatically during npm install — before any of your own code executes — making them the number one real-world vector for supply-chain malware delivery. Legitimate packages that genuinely need install scripts (like node-gyp and imagemin) are automatically whitelisted.

Layer 4 — Deep Tarball AST Scan
Downloads the actual npm tarball for flagged packages and scans every JavaScript and TypeScript file inside it for 14 malware patterns: eval() with encoded payloads, new Function(), vm.runInNewContext(), child_process spawning, dynamic require() calls, Base64-decoded payloads, zero-width and Zalgo character obfuscation, network exfiltration patterns, self-publication via npm publish, and more. This catches threats that registry metadata alone cannot reveal.

Layer 5 — Typosquatting Detection
Detects three classes of package name attacks entirely offline with no network calls. First, classic typosquatting — misspelled names like recat instead of react — using Damerau-Levenshtein edit distance checked against 250+ top npm packages. Second, homoglyph attacks where Unicode look-alike characters (Cyrillic, Greek) replace Latin letters, making reаct look identical to react on screen. Third, AI hallucination squatting — package names that AI coding assistants commonly invent but that do not actually exist on npm, leaving a gap for attackers to register.

Layer 6 — Dependency Confusion
Identifies internal or private package names that have been planted on the public npm registry. Attackers register a name like @yourcompany/internal-utils on public npm with an inflated version number (e.g., 99.0.0). Because npm resolves the highest semver by default, the malicious public package silently wins over your private registry. This layer detects freshly published packages with inflated versions and near-zero download counts under scopes that should be private.

Layer 7 — Registry Risk Heuristics
Scores each package against a set of behavioral signals pulled from the npm registry. The risk score combines: package age (newly published packages score much higher), number of maintainers, weekly download velocity relative to package age, whether the publisher account matches the listed maintainers (a key account-takeover signal), whether the GitHub organization matches the npm publisher, and whether the unpacked package size is suspiciously large. A single flagged signal is informational; multiple signals together produce a High or Critical rating.

Layer 8 — Lockfile Full-Tree Scan
Expands the complete dependency tree from your lockfile and checks every transitive package — not just the ones listed in your package.json. Supports npm lockfile versions 1, 2, and 3, yarn.lock v1, pnpm-lock.yaml versions 5 through 9, and Bun lockfiles. It also validates that every resolved URL points to the standard npm registry, flagging packages silently pulled from alternative or attacker-controlled registries. The 2018 event-stream attack only worked because the malicious payload was three levels deep in the dependency tree — exactly what this layer is designed to catch.

Layer 9 — Overrides / Resolutions CVE Poisoning
Checks the overrides field (npm) and resolutions field (yarn) in your package.json. These fields are commonly used to force a safe version of a transitive dependency — but they can also accidentally or maliciously pin a vulnerable version that overrides a safe one. Every version pinned in these fields is checked against OSV.dev for known CVEs, exactly like direct dependencies.

Layer 10 — Deprecated Packages
Queries the npm registry for the official deprecation flag on each of your packages. Deprecated packages receive no further security patches — any vulnerability discovered after deprecation will remain permanently unpatched. The alert shows the deprecation message left by the maintainer and, where available, the recommended migration path or alternative package.

Layer 11 — License Compliance
Checks the SPDX license identifier of each package against a configurable deny-list. The default deny-list covers licenses that are incompatible with closed-source commercial software: GPL-2.0, GPL-3.0, AGPL-3.0, and SSPL-1.0. AGPL-3.0 in particular requires you to open-source your entire application if you distribute it or run it as a network service. The deny-list is fully customizable per team via a .nsgrc.json file in the project root.

Layer 12 — Unmaintained Packages
Flags packages that have not received a new publish in longer than a configurable threshold, defaulting to 12 months. Unmaintained packages are a common entry point for supply-chain attacks: threat actors acquire abandoned maintainer accounts through credential stuffing or social engineering, then push malicious updates to packages that still have millions of weekly downloads from years-old package.json files that nobody has touched. The age threshold is fully configurable via npmSafetyGuard.unmaintained.months.

Layer 13 — Phantom Dependencies
Scans your entire workspace source code — all .ts, .js, .tsx, and .jsx files — for import and require() statements referencing packages that are not declared in your package.json. These are called phantom dependencies. They appear to work locally because npm hoists packages into a flat node_modules structure, so a package required by one of your declared dependencies is incidentally available to your code. They break silently in CI pipelines, Docker builds, or whenever the transitive provider is updated or removed.

Layer 14 — OSSF Scorecard
Queries the Open Source Security Foundation Scorecard API for each package's GitHub repository and retrieves a security hygiene score from 0 to 10. The score is based on 18 automated checks including: whether branch protection is enforced, whether pull request reviews are required before merging, whether CI tests run on every commit, whether releases are cryptographically signed, and whether known vulnerabilities are tracked and patched. A low score means the project has weak practices and would be easy for an attacker to compromise. The API is free, requires no key, and results are cached for 24 hours.

Layer 15 — Socket.dev Supply Chain Score
Integrates with the Socket.dev API to retrieve deep behavioral supply-chain intelligence for each package. Socket analyzes packages at the AST level before you install them, flagging unexpected environment variable reads, network calls, shell spawning, obfuscated code, and author-change signals that indicate a possible account takeover. Requires a Socket.dev API key. Results are cached for 6 hours.

Layer 16 — ReversingLabs Spectra Assure
An optional premium integration with ReversingLabs, the same binary analysis platform used by enterprise security teams and government agencies. It provides malware classification, tampering detection (identifying when a published package has been modified after upload — a definitive sign of supply-chain compromise), CVE enumeration with fix availability, and C2 callback detection. A free community tier is available for individual developers.

Layer 17 — npm Provenance Attestations
Checks whether each package has a Sigstore-signed provenance attestation, a feature introduced in npm 9.5 in 2023. A provenance attestation cryptographically links the published package to the exact GitHub repository, commit SHA, and CI workflow run that built it. Without an attestation, there is no proof that the published tarball matches what was in the source code — it could have been built locally, tampered with, or published from a compromised machine.

Layer 18 — Package Upgrade Diff Scanner
When you bump a package version, this layer downloads both the old tarball and the new tarball, runs the full 14-pattern AST scan on each, and reports only the patterns that are newly present in the upgraded version. Patterns that existed in both versions are intentionally suppressed to eliminate noise. This means you see exactly what new capabilities or risks were introduced in the upgrade — eval() that was not there before, a new child_process call, an unexpected HTTP request — and nothing else.

Layer 19 — Supply Chain Graph
Renders an interactive force-directed graph of your entire dependency tree inside a VS Code webview. Every node is color-coded by its highest severity finding: red for Critical, orange for High, yellow for Medium, green for clean. Edges connecting risky packages are highlighted. You can pan, zoom, drag nodes, and search. A statistics overlay shows the total package count and a breakdown by risk level. The graph is truncated at 500 nodes, prioritizing the riskiest packages first.

Layer 20 — MCP Server Config Scanner
Scans Model Context Protocol configuration files across your workspace and home directory — including .cursor/mcp.json, .vscode/mcp.json, and ~/.claude/claude_desktop_config.json — for malicious or typosquatted MCP server packages. MCP servers run as persistent background processes inside AI coding sessions like Cursor and Claude Code. A malicious MCP server can intercept every AI query, read your entire codebase, and exfiltrate any API keys passed to it through the env configuration block.

Layer 21 — AI Config Guard
Scans up to three levels deep inside your node_modules directory for packages that contain code designed to target AI developer tool credentials. Using approximately 20 attack signatures, it detects attempts to read Claude Code settings, Cursor configuration, GitHub Copilot tokens, and 1Password CLI credentials, followed by exfiltration patterns like unexpected network calls carrying the stolen data. This layer addresses an emerging class of supply-chain attack specifically targeting the AI-assisted development workflow.

Layer 22 — Exposed Secrets Scanner
Scans your workspace files for accidentally exposed secrets in .env*, .npmrc, *.pem, *.key, credentials.json, and secrets.json files. Detects over a dozen secret types: AWS access keys, Stripe live keys, GitHub Personal Access Tokens, Slack tokens, Google API keys, SendGrid keys, npm auth tokens, private keys in PEM format, and generic API_KEY, SECRET, TOKEN, and PASSWORD patterns. Severity is escalated to Critical if the file is not listed in .gitignore, because the secret will be committed to your repository on the next git commit. Files like .env.example and .env.sample are never scanned.

Layer 23 — Native Binary Detection
Detects precompiled .node binary files inside npm package tarballs. Native Node.js Addons are compiled C or C++ shared libraries that are loaded directly into the Node.js process. They are completely opaque to JavaScript static analysis tools — none of the 14 AST scan patterns in Layer 4, none of the other JS-based layers, can inspect what a .node binary actually does at runtime. Many legitimate packages use native bindings for performance (image processing, database drivers, cryptography), so findings are flagged as High rather than Critical, with guidance to audit the source code on GitHub and consider whether a pure-JavaScript alternative exists.

⭐ Outro
NPM Safety Guard covers the entire threat surface of the npm ecosystem — from known malware databases and CVEs, through behavioral heuristics and tarball analysis, all the way to AI credential targeting and exposed secrets. Most layers require no API keys and work completely offline. Install it once and your entire team is protected on every project, in every file, on every save.

Available free on the VS Code Marketplace (ext install jomynn.npm-safety-guard) and the JetBrains Marketplace. Open source under the MIT license. Built by SendWaveHub.

🔧 INSTALL

VS Code / Cursor / Windsufl:
Search "NPM Safety Guard" in the Extensions panel, or run:
ext install jomynn.npm-safety-guard

JetBrains (WebStorm, IntelliJ IDEA, Rider…):
Settings → Plugins → Marketplace → search "NPM Safety Guard"

🔗 LINKS

VS Code Marketplace → https://marketplace.visualstudio.com/items?itemName=jomynn.npm-safety-guard
JetBrains Marketplace → https://plugins.jetbrains.com/plugin/com.sendwavehub.npmsafetyguard
GitHub (open source, MIT) → https://github.com/jomynn/npm-safety-guard
SendWaveHub → https://sendwavehub.tech

💛 SUPPORT THE PROJECT

⭐ Star the repo on GitHub — it helps more developers discover it
☕ Ko-fi one-off tip → https://ko-fi.com/sendwavehubtech
💖 GitHub Sponsors (recurring) → https://github.com/sponsors/jomynn
🏢 Corporate sponsorship → https://sendwavehub.tech/contact

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

jomynn — Thu, 18 Jun 2026 10:16:30 +0000

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

VS Code / Cursor / Windsurf → VS Code Marketplace
VS Codium / open-source IDEs → Open VSX Registry
WebStorm / IntelliJ IDEA / all JetBrains IDEs → JetBrains Marketplace

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.

How We Catch the Axios DPRK RAT — Directly in Your IDE

jomynn — Fri, 22 May 2026 02:26:06 +0000

Published by SendWaveHub · NPM Safety Guard v1.12.0

The Attack

In April 2025, security researchers discovered that axios 1.14.1 — a package with hundreds of millions of downloads — had been briefly replaced on npm with a version containing a Remote Access Trojan (RAT) attributed to DPRK-linked threat actors (the Lazarus Group).

The malicious version was live for a short window. Developers who ran npm install during that window pulled down a backdoor that connected to attacker-controlled infrastructure.

This isn't an edge case. It's the same pattern used in the event-stream attack (2018), ua-parser-js (2021), and dozens of others. Supply chain attacks now account for a significant share of real-world breaches — and they bypass most traditional security tools because the package itself is the attack vector.

The Problem with Existing Tooling

npm audit only catches known CVEs — it doesn't flag malicious payloads injected into legitimate packages. By the time a CVE is filed, the damage may already be done.

OSV.dev, Snyk, and similar tools are excellent at CVE tracking, but they rely on a package being reported and catalogued. A supply chain attack that's live for 48 hours may never make it into those databases in time to protect you.

What NPM Safety Guard Does Differently

NPM Safety Guard is a free VS Code extension that runs 13 detection layers directly in your editor, before npm install even runs.

For the Axios DPRK RAT specifically, it:

Matches against a curated malicious-package database — the bundled DB includes axios@1.14.1, flagged as CRITICAL with the exact version and attack description
Pulls a live remote feed — updated independently of extension releases, so new attacks light up within hours of discovery
Checks OSV.dev in real time — CVEs filed against your installed versions are flagged inline
Audits install hooks — preinstall/postinstall/prepare scripts are flagged before they run, since they're the #1 supply-chain execution vector

Here's what it looks like when axios@1.14.1 appears in your package.json:

🔴 CRITICAL — DPRK RAT (Lazarus Group) — axios@1.14.1
This version was replaced with a Remote Access Trojan.
Safe version: 1.7.9
npm install axios@1.7.9

The warning appears inline, in the Problems panel, and in a full Security Report — all before you've run a single npm command.

The Other 12 Detection Layers

Catching known-malicious packages is the floor, not the ceiling. NPM Safety Guard also detects:

Layer	What it catches
Typosquatting	`lодash` (Cyrillic о), `expres` — packages designed to look like legitimate ones
Dependency confusion	Scoped packages (`@company/pkg`) that have been planted on public npm
Overrides/resolutions poisoning	Teams pin versions to fix a transitive CVE, accidentally pinning to a vulnerable version
Phantom dependencies	Packages your code imports but aren't in `package.json` — fail silently in clean installs
Unmaintained packages	Last release >24 months ago → accumulating unpatched CVEs
Deprecated packages	npm-deprecated packages with auto-upgrade suggestions
Install script audit	Every `preinstall`/`postinstall` hook flagged with package context
OSSF Scorecard	Security hygiene scores from the OpenSSF for each dependency
Socket.dev integration	Supply chain risk scores (requires token)
License compliance	GPL/AGPL in commercial projects
ReversingLabs	Real-time CVE + malware detection (requires free token)
Lockfile scan	Full resolved dependency tree, not just direct deps

Install It Free

The extension is free, open source (MIT), and available on:

VS Code Marketplace
Open VSX (for VSCodium users)

ext install Sendwavehubtech.npm-safety-guard

No API key required for the core features. The malware DB and OSV.dev integration work out of the box.

Why This Matters Now

The Axios attack was caught relatively quickly — but only because it targeted a high-profile package with many eyes on it. The next attack will target a smaller package, with fewer watchers, and stay live longer.

Your best defense is catching the package before it's installed — at the point where you're editing package.json in your editor.

That's exactly what NPM Safety Guard is built for.

Built by SendWaveHub. If this saves your project, consider sponsoring the work.

Tags: security npm javascript devsecops supplychain