How to Check npm Packages for Security Vulnerabilities

Why npm audit Is Not Enough

Most developers know about npm audit. You run it, it tells you about vulnerabilities, you feel like you have done your due diligence. The problem is that npm audit only checks the npm advisory database - a subset of the full vulnerability landscape. It misses vulnerabilities reported in other databases and does not check Python dependencies at all if you have a mixed project.

More importantly, npm audit gives you a number (usually alarming) without much context about which vulnerabilities actually matter in your specific usage. A critical vulnerability in a package you use only in tests is very different from a critical vulnerability in a package that handles user input in production.

How CVE Databases Work

A CVE (Common Vulnerability and Exposures) is a unique identifier assigned to a publicly known security vulnerability. CVE-2021-44228 is Log4Shell. CVE-2019-10744 is the lodash prototype pollution vulnerability. The CVE ID is the universal reference - you can search it in any security database and get consistent information.

MITRE Corporation assigns CVE IDs. The National Vulnerability Database (NVD) scores them using CVSS. The GitHub Security Advisory database tracks vulnerabilities in open source packages specifically. Google's OSV (Open Source Vulnerability) database aggregates all of these - NVD, GitHub Security Advisories, PyPI advisories, and more - into a single normalized format.

The OSV database is what powers GitHub's Dependabot and the npm audit command. It is also what the Queldrex Dependency CVE Scanner queries directly - which means you get the same data that Dependabot uses, without needing to push your code to GitHub.

What CVSS Scores Actually Mean

CVSS (Common Vulnerability Scoring System) scores vulnerabilities from 0 to 10 based on how exploitable they are and what damage they can cause. The number tells you the severity tier:

• 0.0 – 3.9 (Low) - Exploitable but limited impact. Usually requires unusual conditions or significant attacker effort. Fix it, but not urgently.
• 4.0 – 6.9 (Medium) - Exploitable under specific conditions. May require local access or a particular configuration. Should be fixed in a normal release cycle.
• 7.0 – 8.9 (High) - Serious. Remotely exploitable or with significant impact on confidentiality, integrity, or availability. Fix in your next release.
• 9.0 – 10.0 (Critical) - Remotely exploitable, no authentication required, full compromise possible. Log4Shell was a 10.0. Fix immediately - today if possible.

The CVSS score is a baseline, not context-aware. A 9.0 vulnerability in a package you only use to generate test fixtures during CI - where the vulnerability requires user-controlled input to trigger - is practically zero risk in your environment. A 5.0 vulnerability in a package that parses untrusted user data in your API could be your biggest risk. Read the advisory, not just the number.

The Fix Version Field

Every vulnerability report includes a "fixed in version" field - the specific package version where the maintainers patched the issue. This is what you need to upgrade to. For most advisories, the fix is straightforward: run npm update packagename or pin the specific version in your package.json.

The complication: sometimes the fixed version is a major version bump with breaking changes. lodash 3.x to 4.x introduced breaking API changes, so upgrading is not always a drop-in. In those cases, check the advisory for workarounds - sometimes there is a way to neutralize the vulnerability without upgrading, or you can upgrade only the vulnerable code paths.

After upgrading, re-run your dependency scan to confirm the advisory no longer appears. Then re-run your tests. Then update your lockfile and commit the changes so everyone on the team gets the fixed versions.

Scanning Without Pushing to GitHub

If your project is private, or if you want to check before committing, you do not need Dependabot. The Queldrex Dependency CVE Scanner lets you paste your package.json or requirements.txt directly into a form and get a full vulnerability report from the OSV database - CVE IDs, CVSS scores, fix versions, and links to the full GitHub Security Advisories. No account required, no code leaves your clipboard.

It supports both npm (package.json) and Python (requirements.txt), which makes it useful for full-stack projects where both ecosystems are in play. Paste, scan, fix - no pipeline setup required.

Building Dependency Scanning Into Your Workflow

The best time to catch a vulnerable dependency is before it ships. A few practices that help:

• Scan before every major release - paste your current package.json and check for new advisories before you cut a release branch.
• Enable Dependabot on GitHub - it creates automated PRs when new advisories appear for your dependencies.
• Use exact versions in package.json - "lodash": "4.17.21" instead of "^4.17.0". This prevents automatic upgrades that could introduce different vulnerabilities.
• Review the advisory, not just the score - understand whether the vulnerable code path is reachable in your application before declaring an emergency.