npm Dependency Security Checklist

Your application inherits the security posture of every package in your dependency tree. With over 500 malicious packages released into npm earlier this year and 80% of npm vulnerabilities surfacing through dependency injection paths, you need a systematic approach to package vetting and ongoing monitoring.

This checklist provides a repeatable process for evaluating npm packages before installation and maintaining security hygiene across your existing dependencies.

Prerequisites

Before you begin:

• Package manager access: Ensure you have npm CLI or yarn with permission to inspect package contents.
• Dependency visualization tool: Install npmgraph.an or a similar tool for tree analysis.
• Vulnerability scanner: Set up Snyk, npm audit, or your organization's approved scanning tool.
• Documentation access: Maintain a register of approved packages and vetting decisions.

Package Vetting Checklist

Before Installation

1. Verify package authenticity

• Confirm the package name matches your intended dependency exactly (no typosquatting).
• Check the package author's npm profile for other published packages.
• Verify the GitHub repository link in package.json points to legitimate source code.
• Good looks like: The package name, author, and repository align with the official project documentation you found through independent research.

2. Assess package maintenance status

• Review the last publish date (flag if over 12 months without updates).
• Check open issues count and maintainer response patterns.
• Verify the package has more than one active maintainer.
• Good looks like: Regular commits within the last quarter, maintainers responding to security issues within 7 days, and a documented succession plan for the project.

3. Analyze dependency depth

• Run npm ls <package-name> to preview the full dependency tree.
• Count transitive dependencies (flag if over 50 for a single package).
• Identify any deprecated packages in the tree.
• Good looks like: A shallow tree with fewer than 20 transitive dependencies, all actively maintained, with clear justification for each layer.

4. Review package permissions and behavior

• Examine package.json for preinstall, postinstall, or preuninstall scripts.
• Check for network calls in install scripts.
• Verify the package doesn't request filesystem access beyond node_modules.
• Good looks like: No install scripts, or scripts that only compile native modules with transparent build processes. Any script that touches the network during installation is a red flag requiring deeper investigation.

5. Run security scans

• Execute npm audit or Snyk scan before adding the package.
• Review CVE details for any flagged vulnerabilities.
• Check if patches or alternative packages exist.
• Good looks like: Zero high or critical vulnerabilities, with a documented decision for any medium-severity findings you accept.

Post-Installation

6. Document vetting decisions

• Record package name, version, and vetting date in your dependency register.
• Note any security findings and accepted risks.
• Set a review date (typically 90 days for critical path dependencies).
• Good looks like: A spreadsheet or wiki page that any team member can reference, showing who approved each package and under what conditions.

7. Configure automated monitoring

• Add the package to your CI/CD vulnerability scanning.
• Set up notifications for new CVEs affecting this package.
• Enable automated PR creation for security updates.
• Good looks like: Snyk or Dependabot configured to scan on every commit and create PRs within 24 hours of a security advisory.

Quarterly Review

8. Audit your complete dependency tree

• Generate a full dependency report with npm ls --all.
• Identify packages you didn't directly install (transitive dependencies).
• Flag any dependencies that haven't been updated in over 6 months.
• Good looks like: A visualization showing your top 10 packages by transitive dependency count, with a plan to reduce or replace the heaviest ones.

9. Review and update pinned versions

• Check for available security patches for pinned dependencies.
• Test updates in a staging environment.
• Update package-lock.json and commit changes.
• Good looks like: All direct dependencies updated to their latest stable minor version, with major version updates scheduled and tested.

Common Mistakes

Trusting npm download counts as a security signal: Popular packages can still be compromised. Vet every update.

Ignoring transitive dependencies: You're responsible for the entire tree. Use npm ls to understand what you're really adding.

Running npm audit fix blindly: Automated fixes can break your application. Review proposed changes and test in staging.

Skipping install script review: Packages can execute arbitrary code during installation. Investigate any postinstall scripts that download executables or modify files outside node_modules.

Treating vulnerability scanners as complete solutions: Tools like Snyk and npm audit catch known CVEs, but won't detect new malicious packages. Combine automated scanning with manual vetting for critical dependencies.

Next Steps

Start with your 10 most-used packages. Run them through this checklist and document your findings. Then:

1. Set up continuous monitoring: Configure Snyk or npm audit in your CI pipeline to scan on every commit.
2. Establish a review cadence: Schedule quarterly dependency audits on your team calendar.
3. Create an approved package list: Document which packages passed vetting and which are banned.
4. Train your team: Share this checklist and make package vetting part of your code review process.

For PCI DSS v4.0.1 compliance, this checklist supports Requirement 6.3.2 (inventory of bespoke and custom software and third-party components) and Requirement 6.4.3 (managing vulnerabilities in custom and bespoke software). For SOC 2 Type II, this addresses CC7.1 (detecting and responding to security events) and CC8.1 (change management).

The dependency tree you build today determines your security posture tomorrow. Make vetting systematic, not optional.