Dependency Vulnerability Scanning: Why Your npm Audit Is Not Enough

Most engineering teams run some form of dependency scanning. They use npm audit, Dependabot alerts, or Snyk on their CI pipeline. Yet supply chain attacks and dependency-related breaches continue to increase year over year. The gap between "we scan dependencies" and "we are secure" is larger than most teams realize.

What npm audit Actually Checks

The npm audit command queries the npm advisory database for known CVEs in your direct and transitive dependencies. It is fast, free, and runs in seconds. It is also limited in three important ways.

First, it only catches vulnerabilities that have been publicly disclosed and catalogued. A malicious package published last week with no CVE assigned is invisible to npm audit until a report is filed and reviewed.

Second, npm audit grades severity based on CVSS scores that do not account for your specific application context. A critical-severity vulnerability in a package you use only for build tooling is genuinely lower risk than a medium-severity vulnerability in a package handling authentication tokens. Raw CVSS scores without context lead teams to chase low-impact fixes while ignoring high-impact ones.

Third, npm audit does not examine how a dependency is actually used in your code. A vulnerable function in a package may be unreachable from your application entirely, making the vulnerability unexploitable. Without reachability analysis, your audit backlog fills with noise.

Transitive Dependency Risk

The average Node.js application has over 1,000 transitive dependencies — packages your direct dependencies depend on, and their dependencies, and so on. You declare perhaps 30 direct dependencies in your package.json. The full dependency tree is orders of magnitude larger.

The 2021 ua-parser-js attack demonstrated this clearly: a widely used package was temporarily hijacked by a malicious actor who published a version containing a cryptocurrency miner and password stealer. Thousands of projects were affected, not because they had declared a dependency on ua-parser-js directly, but because something else in their tree had.

Comprehensive dependency scanning requires visualizing and monitoring the entire dependency graph, not just the first layer.

Supply Chain Attack Vectors npm audit Misses

Typosquatting

Attackers publish packages with names one character different from popular packages: lodahs instead of lodash, expres instead of express. Developers installing unfamiliar packages under deadline pressure are the primary target. Scanning tools that only check CVE databases cannot detect a malicious package that has no advisory yet.

Dependency Confusion

If your organization uses private package registries, an attacker can publish a public package with the same name as your private package but a higher version number. Package managers configured to check public registries may pull the malicious public version instead of your private one. This attack vector requires configuration-level scanning, not just CVE checking.

Abandoned Maintainer Accounts

Popular packages whose original maintainers have moved on are high-value targets for account takeover. Once an attacker controls the npm account of a maintainer with millions of weekly downloads, they can publish a new version with malicious code and it will automatically pull into thousands of projects. Monitoring maintainer account age and activity is part of a mature dependency security program.

License Compliance: The Hidden Dependency Risk

Security teams focus on CVEs, but legal and compliance teams have a parallel concern: license obligations. If a transitive dependency carries a copyleft license such as GPL, it may impose obligations on your proprietary codebase that your legal team needs to evaluate. Enterprise sales processes increasingly include software composition analysis reports that map the license of every dependency in your tree.

License scanning is rarely included in basic npm audit output. It requires a separate tool or a more comprehensive audit process.

What Comprehensive Dependency Scanning Looks Like

A security-mature dependency scanning program combines four capabilities:

1. CVE matching against multiple databases (NVD, GitHub Advisory, OSV) with deduplication
2. Reachability analysis to determine whether vulnerable functions are actually called in your application
3. Behavioral analysis to detect packages that make unexpected network calls, access the filesystem in unusual ways, or execute shell commands during install
4. License compliance mapping across the full dependency tree

Running these checks on every pull request catches new vulnerabilities before they merge. Running them on a scheduled basis catches vulnerabilities disclosed after your last merge. Both cadences are necessary.

Integrating Dependency Scanning Into Your Engineering Workflow

The most effective dependency scanning programs fail CI builds only on exploitable Critical and High vulnerabilities with available fixes. Failing on every advisory regardless of severity trains engineers to dismiss alerts as noise, which defeats the purpose.

Findings with no available fix should route to a tracked backlog rather than blocking deployment. The team needs visibility, but shipping cannot stop for an upstream vulnerability with no patch available.

Quarterly full-codebase dependency audits complement automated CI scanning by providing a comprehensive snapshot useful for compliance evidence, insurance questionnaires, and enterprise security reviews.

How MergeProof Approaches Dependency Scanning

MergeProof dependency audits examine your full dependency tree against multiple advisory databases, flag license compliance issues, and provide a prioritized remediation list organized by exploitability rather than raw CVSS score. Reports are formatted to satisfy the dependency management evidence requirements of SOC 2, HIPAA, and ISO 27001 auditors.