Pre-deploy security guide

How to audit npm packages for security before deploying

Most teams run npm audit and stop there. That catches CVEs — but it misses abandoned packages that will never receive a patch, copyleft licenses that can create legal exposure, and typosquatted names that run attacker code at install time. This guide covers the complete pre-deploy audit workflow.

• What npm audit misses
• Step 1: CVE scan
• Step 2: Abandoned & deprecated packages
• Step 3: License risk
• Step 4: Typosquatting
• Step 5: Wire up CI
• Pre-deploy checklist
• FAQ

What npm audit misses — and why it matters

npm audit queries the npm advisory database for packages in your dependency tree that have a published CVE or security advisory. That is genuinely useful — but the advisory database only knows about known problems that have been formally reported. It tells you nothing about:

Risk category	npm audit	Full audit
Published CVEs and security advisories	✓ Yes	✓ Yes
Packages with no recent releases (abandoned)	✗ No	✓ Yes
Packages deprecated by their own maintainer	✗ No	✓ Yes
Copyleft licenses (GPL, AGPL) incompatible with commercial use	✗ No	✓ Yes
Typosquatted package names	✗ No	✓ Yes
Packages with zero downloads or no documentation	✗ No	✓ Yes

Each gap represents a real category of incident: supply-chain attacks via abandoned packages, open-source license disputes, and typosquat attacks that run malicious install scripts. The pre-deploy workflow below covers all of them.

Step 1: Run npm audit locally before pushing

Start with the built-in CVE scan. The goal here is to run it before pushing to your branch — not as an afterthought in a CI failure email.

# Full audit report
npm audit

# JSON output for programmatic processing
npm audit --json

# Fail only on high and critical (useful in CI, see Step 5)
npm audit --audit-level=high

Read the output before moving on. Each advisory includes a severity, the affected package and version range, the dependency chain that brought it in, and the fixed version (if one exists). Anything at high or critical severity warrants a fix before you deploy — see the npm audit remediation guide for every fix path.

Step 2: Check for abandoned and deprecated packages

This is the gap npm audit does not fill. A package that was last updated in 2020 and has no open issues being addressed will never receive a security patch — any future CVE is a permanent exposure. Similarly, a package marked deprecated in the npm registry is signaling that the maintainer considers it dead and unsafe to use.

Two ways to check:

Option A: npm info per-package (for spot checks)

# See when a package was last published
npm info lodash time.modified

# See if a package is deprecated
npm info some-package deprecated

This works for checking a specific package you're unsure about, but it doesn't scale across 50 or 100 dependencies.

Option B: Paste your package.json into DepCheck (full sweep)

Paste your package.json into DepCheck to get a severity-sorted report covering abandoned packages, deprecated packages, typosquatting risk, and copyleft licenses across all your dependencies at once — in the browser, without sending your code anywhere.

Scan your package.json with DepCheck →

Pay particular attention to packages with no release in 24+ months that are in your production dependency list (not just devDependencies). For each flagged abandoned package, check: (1) is there a maintained fork? (2) is there a modern equivalent in the ecosystem? (3) how much of the API do you actually use — could it be replaced with a few lines of native code?

Step 3: Check for license risk

The npm ecosystem contains packages under hundreds of different licenses. Most popular packages use MIT, BSD, Apache 2.0, or ISC — all permissive, all safe for commercial use. But some use copyleft licenses that impose obligations on your own code:

• GPL-2.0 / GPL-3.0 — if your software links against a GPL package and is distributed, your entire codebase must be released under GPL. "Distributed" typically means shipping a desktop/mobile app, not running a server.
• LGPL-2.1 / LGPL-3.0 — weaker copyleft; usually safe if you link dynamically and don't modify the library. Static linking is murkier.
• AGPL-3.0 — the strongest copyleft for server software. If you run an AGPL-licensed package as a network service (which includes almost every web application), you must release your entire application source under AGPL. This affects many AI/ML libraries.
• EUPL — a European Union copyleft license; similar obligations to LGPL, but interacts differently with other copyleft licenses.

To check a specific dependency:

npm info package-name license

To audit your full tree for copyleft licenses, paste your package.json into DepCheck — it flags GPL, LGPL, AGPL, and EUPL dependencies by severity.

Step 4: Watch for typosquatting when installing new packages

Typosquatting attacks target developers who make a typo during npm install. A package named expres, lodahs, or crossenv may look harmless in the terminal output but runs a postinstall script that exfiltrates environment variables, SSH keys, or AWS credentials before you see any error — and the code runs during npm install, before you ever import the package.

Before installing any new package, especially one you heard about in a tutorial or Stack Overflow answer:

1. Double-check the exact name on npmjs.com — look at the download count, the GitHub link, and the publisher account age.
2. Check how many packages that publisher account has published. A single package on a brand-new account is a yellow flag.
3. Look at the package.json on the registry page and check the scripts.postinstall field before installing.

DepCheck also flags packages whose names are suspiciously similar to popular packages in its typosquatting heuristic — worth running after any batch of new installs. For a deeper look at how the attack works and a complete verification workflow, see the npm typosquatting detection guide.

Step 5: Wire the audit into your CI/CD pipeline

Local audits are a safety net; CI enforcement is the gate. Add these checks to your workflow so no deployment bypasses them.

GitHub Actions example

name: Dependency security audit
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  schedule:
    - cron: '0 9 * * 1'  # Weekly Monday 9 AM UTC

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies (exact lockfile)
        run: npm ci

      - name: Run security audit
        run: npm audit --audit-level=high
        # Fails build on high/critical; low/moderate appear in log but don't block

Pre-commit hook (optional second line of defence)

# .git/hooks/pre-push  (make executable: chmod +x .git/hooks/pre-push)
#!/bin/sh
npm audit --audit-level=critical
if [ $? -ne 0 ]; then
  echo "Critical npm audit vulnerability found. Push blocked."
  echo "Run: npm audit fix  (or see the remediation guide)"
  exit 1
fi

This blocks a push to the remote if any critical vulnerability is in the tree at push time — a useful backstop for developers who forget to audit locally.

Pre-deploy dependency checklist

• Run npm audit — no high or critical findings outstanding
• Paste package.json into DepCheck — no abandoned or deprecated packages in production deps
• No copyleft licenses (AGPL, GPL, LGPL) in the flagged list that conflict with your commercial use
• No typosquatting flags for recently installed packages
• CI runs npm ci (not npm install) and npm audit --audit-level=high on every push to main
• A weekly scheduled audit cron is active in CI
• package-lock.json committed and up to date in the repo

Run the DepCheck scan →

Frequently asked questions

Also in the Copper Bay Labs ship-safety suite

Dependencies are one layer of your security posture. These free tools cover the rest before you ship: