Free Security Tool — SCA for npm
Paste your package.json to instantly scan for vulnerable, outdated, and EOL npm packages. Detects 50+ known CVE patterns with severity ratings and fix commands. No npm install, no CLI, no login required.
// Paste package.json contents
Dependency scanning, also called Software Composition Analysis (SCA), is the automated process of analyzing the third-party libraries and packages your application uses to identify known security vulnerabilities, outdated versions, and end-of-life components. Unlike SAST (which analyzes your own code), dependency scanning inspects the external open-source components you import.
Modern applications contain hundreds of external dependencies. A typical Node.js project may directly list 30-50 packages in package.json, but the full dependency tree — including transitive dependencies — often reaches into the thousands. Each of those packages represents potential attack surface: a vulnerability in any one of them can compromise your entire application.
Dependency scanning works by reading your project's manifest file (package.json for Node.js, requirements.txt for Python, pom.xml for Java) and comparing the listed package versions against a vulnerability database. When a package version matches a known CVE, the scanner flags it with severity, description, and a remediation path. This tool does exactly that for npm packages — instantly, in your browser.
Unlike npm audit, this tool requires no installed node_modules, no project directory, and no npm registry connection. Paste your package.json and get results in under a second.
package.json file in your project root. Copy its full contents — both dependencies and devDependencies are scanned.
npm install command to fix it.
package.json to confirm the score improves.
The scanner checks your package versions against 50+ known vulnerable npm packages across all severity levels.
critical //
Known CVE PackagesDetects packages with documented critical CVEs: lodash (prototype pollution), minimist (prototype pollution), jsonwebtoken (algorithm confusion), tar (path traversal), underscore (code execution).
high //
SSRF & XSS VulnerabilitiesFlags axios versions with SSRF risk, serialize-javascript with XSS, node-fetch with credential exposure, express with open redirect via qs.
medium //
ReDoS VulnerabilitiesDetects packages with Regular Expression Denial of Service patterns: marked, semver, ansi-regex, glob-parent, normalize-url, word-wrap, terser.
eol //
Deprecated & EOL PackagesFlags unmaintained packages with no future security patches: node-sass (replaced by sass), request (deprecated, replace with axios or got).
score //
Security ScoreCalculates an overall dependency health score (0-100) weighted by severity. Critical findings have 3x impact, High 2x, Medium 1x. Aim for 80+ before deploying.
fix //
Fix CommandsFor every vulnerable package, the scanner shows the safe minimum version and the exact npm install pkg@version command to apply the fix immediately.
A transitive dependency (also called an indirect dependency) is a package that your direct dependency requires to function. When you install express, it installs dozens of its own dependencies — and each of those may have their own. The full chain can reach hundreds of packages deep, none of which appear in your package.json.
Transitive dependency vulnerabilities are CVEs in these indirect packages. They are the most dangerous category in dependency security because they are completely invisible — you never chose to install them, they don't appear in your manifest, and they can be introduced silently when you update a direct dependency to a new minor version.
The most infamous example is Log4Shell (CVE-2021-44228) — a critical RCE vulnerability in the Log4j Java library. Thousands of organizations were affected not because they intentionally used Log4j, but because it was a transitive dependency of other libraries they used. The same pattern recurs constantly in the npm ecosystem.
This tool scans your direct dependencies from package.json. For full transitive dependency scanning, use npm audit (requires installed node_modules) or Snyk (requires an account). Use this tool for fast pre-commit checks on your direct packages.
Browser-based scanners like this tool are ideal for quick manual checks. But in a DevSecOps workflow, dependency scanning should run automatically on every pull request and build — catching vulnerable packages before they reach production.
GitLab's built-in dependency scanning (available on Ultimate tier) integrates directly into merge requests and shows vulnerability diffs between branches. GitHub's Dependabot automatically opens PRs when new CVEs are disclosed for your dependencies. Both use live vulnerability databases updated in real time — a significant advantage over static pattern matching.
The recommended layered approach: use this tool for instant pre-commit checks with no setup, then npm audit in your local workflow, then Snyk or GitLab dependency scanning as your CI/CD gate for full transitive coverage before merging.
Multiple dependency scanning tools exist at different levels of depth, setup, and coverage. The right tool depends on your context — quick manual check, local workflow, or automated CI/CD gate.
| Tool | This Scanner | npm audit | Snyk | OWASP Dep-Check |
|---|---|---|---|---|
| Requires install | ✓ No | ✗ npm + node_modules | ✗ CLI + account | ✗ Java CLI |
| Transitive deps | — Direct only | ✓ Full tree | ✓ Full tree | ✓ Full tree |
| Live CVE database | — Pattern-based | ✓ npm advisory DB | ✓ Snyk DB + NVD | ✓ NVD + more |
| Login required | ✓ No account | ✓ No account | ✗ Account needed | ✓ No account |
| CI/CD integration | — Manual | ✓ Native npm | ✓ GitHub, GitLab | ✓ Jenkins, Maven |
| Languages supported | — npm only | — npm only | ✓ 10+ languages | ✓ Java, .NET, Python |
| Free | ✓ Always free | ✓ Free | — Free tier limited | ✓ Open source |
Use this tool for quick manual checks on direct dependencies. Use npm audit in your local workflow. Use Snyk or GitLab dependency scanning as your CI/CD gate for full transitive coverage.
Common questions from developers and security engineers dealing with npm vulnerabilities — the kind of discussions found on Reddit r/devops, Stack Overflow, and DevSecOps communities.
How do I know if my npm packages have security vulnerabilities without running npm install?
Paste your package.json into this scanner. It checks your listed versions against 50+ known vulnerable package patterns instantly in the browser — no project setup, no node_modules, no npm registry connection. For comprehensive coverage including transitive dependencies, you'll need npm audit with node_modules installed, but this tool catches the most common direct dependency CVEs immediately.
What's the fastest way to find and fix a specific vulnerability like lodash prototype pollution?
Check your package.json for the lodash version. If it's below 4.17.21, you're affected by CVE-2020-8203 and CVE-2021-23337. Run npm install lodash@4.17.21 to update. Then run npm audit to check if any other packages in your tree also depend on an older lodash version transitively — if so, you may need to add an overrides entry in your package.json.
Should I scan devDependencies for vulnerabilities?
Yes, even devDependencies matter. Build tools like webpack, babel, and jest run in your development and CI/CD environment with access to your source code and secrets. A vulnerable devDependency can be exploited in a supply chain attack targeting your build pipeline. This scanner checks both dependencies and devDependencies by default.
What is prototype pollution and why does it affect so many npm packages?
Prototype pollution is a JavaScript vulnerability where an attacker injects properties into Object.prototype, affecting all objects in the runtime. It's particularly common in npm utility packages that merge, clone, or deeply extend objects without sanitizing keys like __proto__ or constructor. Affected packages include lodash, minimist, async, jsonschema, and many others. It can lead to denial of service, authentication bypass, or even remote code execution depending on the context.
How often should I run dependency scanning on my project?
At minimum, before every production release. Ideally, on every pull request via CI/CD — new CVEs are disclosed daily, and a package that was clean this morning may be vulnerable by afternoon. Set up GitHub Dependabot or GitLab's dependency scanning to automatically open PRs when new advisories affect your packages. Use this browser tool for quick spot-checks when you add a new package or update a major version.
What's the difference between SCA and SAST in terms of what they protect against?
SCA (Software Composition Analysis / dependency scanning) protects against risks in the code you import — third-party libraries with known CVEs, outdated versions, and supply chain attacks. SAST (Static Application Security Testing) protects against risks in your own code — SQL injection, XSS, insecure deserialization, hardcoded secrets, and logic flaws. Both are essential: SAST can't find vulnerabilities in npm packages, and SCA can't find SQL injection in your controllers. Use both in your secure development pipeline.
npm audit queries the live npm advisory database and scans your full dependency tree including transitive packages — it requires node_modules to be installed. This tool performs instant client-side analysis of your package.json against 50+ known CVE patterns with no installation, no npm registry connection, and your code stays private in the browser.npm audit or Snyk for comprehensive transitive scanning.npm audit fix for automatic safe fixes, or manually update specific packages with npm install PACKAGE@SAFE_VERSION. For breaking changes, use npm audit fix --force and test thoroughly. Add an overrides field in package.json to force safe versions of transitive dependencies you can't update directly.