{"slug": "npm-safety-guard-all-23-security-layers-explained", "title": "🛡️ NPM Safety Guard — All 23 Security Layers Explained", "summary": "NPM Safety Guard, a comprehensive npm security scanner available as a VS Code extension and JetBrains plugin, detects supply-chain threats that npm audit misses. It employs 23 detection layers including known malicious packages, CVE vulnerabilities, install script hooks, deep tarball AST scans, typosquatting detection, dependency confusion, and registry risk heuristics to protect against malware, credential leaks, and AI credential theft.", "body_md": "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.\n\nThis 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.\n\n🛡️ Intro\n\nNPM 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.\n\nLayer 1 — Known Malicious Packages\n\nChecks 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.\n\nLayer 2 — CVE Vulnerabilities\n\nQueries 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.\n\nLayer 3 — Install Script Hooks\n\nFlags 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.\n\nLayer 4 — Deep Tarball AST Scan\n\nDownloads 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.\n\nLayer 5 — Typosquatting Detection\n\nDetects 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.\n\nLayer 6 — Dependency Confusion\n\nIdentifies 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.\n\nLayer 7 — Registry Risk Heuristics\n\nScores 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.\n\nLayer 8 — Lockfile Full-Tree Scan\n\nExpands 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.\n\nLayer 9 — Overrides / Resolutions CVE Poisoning\n\nChecks 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.\n\nLayer 10 — Deprecated Packages\n\nQueries 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.\n\nLayer 11 — License Compliance\n\nChecks 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.\n\nLayer 12 — Unmaintained Packages\n\nFlags 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.\n\nLayer 13 — Phantom Dependencies\n\nScans 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.\n\nLayer 14 — OSSF Scorecard\n\nQueries 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.\n\nLayer 15 — Socket.dev Supply Chain Score\n\nIntegrates 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.\n\nLayer 16 — ReversingLabs Spectra Assure\n\nAn 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.\n\nLayer 17 — npm Provenance Attestations\n\nChecks 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.\n\nLayer 18 — Package Upgrade Diff Scanner\n\nWhen 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.\n\nLayer 19 — Supply Chain Graph\n\nRenders 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.\n\nLayer 20 — MCP Server Config Scanner\n\nScans 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.\n\nLayer 21 — AI Config Guard\n\nScans 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.\n\nLayer 22 — Exposed Secrets Scanner\n\nScans 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.\n\nLayer 23 — Native Binary Detection\n\nDetects 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.\n\n⭐ Outro\n\nNPM 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.\n\nAvailable 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.\n\n🔧 INSTALL\n\nVS Code / Cursor / Windsufl:\n\nSearch \"NPM Safety Guard\" in the Extensions panel, or run:\n\next install jomynn.npm-safety-guard\n\nJetBrains (WebStorm, IntelliJ IDEA, Rider…):\n\nSettings → Plugins → Marketplace → search \"NPM Safety Guard\"\n\n🔗 LINKS\n\nVS Code Marketplace → [https://marketplace.visualstudio.com/items?itemName=jomynn.npm-safety-guard](https://marketplace.visualstudio.com/items?itemName=jomynn.npm-safety-guard)\n\nJetBrains Marketplace → [https://plugins.jetbrains.com/plugin/com.sendwavehub.npmsafetyguard](https://plugins.jetbrains.com/plugin/com.sendwavehub.npmsafetyguard)\n\nGitHub (open source, MIT) → [https://github.com/jomynn/npm-safety-guard](https://github.com/jomynn/npm-safety-guard)\n\nSendWaveHub → [https://sendwavehub.tech](https://sendwavehub.tech)\n\n💛 SUPPORT THE PROJECT\n\n⭐ Star the repo on GitHub — it helps more developers discover it\n\n☕ Ko-fi one-off tip → [https://ko-fi.com/sendwavehubtech](https://ko-fi.com/sendwavehubtech)\n\n💖 GitHub Sponsors (recurring) → [https://github.com/sponsors/jomynn](https://github.com/sponsors/jomynn)\n\n🏢 Corporate sponsorship → [https://sendwavehub.tech/contact](https://sendwavehub.tech/contact)", "url": "https://wpnews.pro/news/npm-safety-guard-all-23-security-layers-explained", "canonical_source": "https://dev.to/jomynn/npm-safety-guard-all-23-security-layers-explained-1l0", "published_at": "2026-06-29 06:20:23+00:00", "updated_at": "2026-06-29 06:57:29.990802+00:00", "lang": "en", "topics": ["developer-tools", "ai-safety", "ai-products"], "entities": ["NPM Safety Guard", "VS Code", "JetBrains", "WebStorm", "IntelliJ IDEA", "Cursor", "Windsurf", "Google OSV.dev"], "alternates": {"html": "https://wpnews.pro/news/npm-safety-guard-all-23-security-layers-explained", "markdown": "https://wpnews.pro/news/npm-safety-guard-all-23-security-layers-explained.md", "text": "https://wpnews.pro/news/npm-safety-guard-all-23-security-layers-explained.txt", "jsonld": "https://wpnews.pro/news/npm-safety-guard-all-23-security-layers-explained.jsonld"}}