Dependency Security

Manage third-party dependency risks with auditing, lockfiles, automated scanning, and supply chain hardening

When to Use

• Adding new dependencies to a project
• Setting up automated vulnerability scanning in CI
• Responding to a CVE in a dependency
• Reviewing the dependency tree for unnecessary packages
• Hardening the supply chain against typosquatting and malicious packages

Instructions

1. Run

   npm audit

   regularly and in CI. It checks installed packages against the npm advisory database for known vulnerabilities.

# Check for vulnerabilities
npm audit

# Fix automatically where possible
npm audit fix

# Only report high and critical severity
npm audit --audit-level=high

# CI gate — fail build on high/critical vulnerabilities
npm audit --audit-level=high --production

2. Always commit lockfiles.

   package-lock.json

   ,

   yarn.lock

   , or

   pnpm-lock.yaml

   pin exact dependency versions. Without a lockfile,

   npm install

   can silently install different (potentially compromised) versions.

3. Set up automated dependency updates with Dependabot or Renovate.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    open-pull-requests-limit: 10
    groups:
      dev-dependencies:
        dependency-type: development
        update-types: [minor, patch]
      production-dependencies:
        dependency-type: production
        update-types: [patch]
    ignore:
      - dependency-name: '*'
        update-types: ['version-update:semver-major']

4. Review new dependencies before adding them. Check these criteria:

# Check package health signals
npm info <package> # Last publish date, maintainers, weekly downloads
npx is-my-dep-secure <package> # Security audit

# Manual checklist:
# - Actively maintained? (commits within last 6 months)
# - Trusted maintainer? (known individual or organization)
# - Reasonable download count? (not a typosquat of a popular package)
# - Small dependency tree? (fewer transitive deps = smaller attack surface)
# - License compatible? (MIT, Apache-2.0, ISC are safe for commercial use)

5. Use

   --ignore-scripts

   for untrusted packages. Postinstall scripts can execute arbitrary code. Disable them globally and whitelist trusted packages.

# Disable all lifecycle scripts globally
npm config set ignore-scripts true

# Allow specific packages
npx allow-scripts

# Or use package.json
{
  "scripts": {
    "preinstall": "npx only-allow pnpm"
  }
}

6. Pin critical production dependencies. For security-sensitive packages (auth, crypto, parsing), use exact versions instead of semver ranges.

{
  "dependencies": {
    "jsonwebtoken": "9.0.2",
    "bcrypt": "5.1.1",
    "helmet": "7.1.0"
  }
}

7. Monitor for vulnerabilities continuously. Use GitHub's security alerts, Snyk, or Socket.dev for real-time notifications when new CVEs affect your dependencies.

# GitHub Actions — run audit on every PR
- name: Security audit
  run: npm audit --audit-level=high --production

8. Remove unused dependencies. Dead dependencies still introduce risk. Use

   depcheck

   to find unused packages.

npx depcheck
# Lists unused dependencies, missing dependencies, and unused devDependencies

9. Use Subresource Integrity (SRI) for CDN-loaded scripts. If loading JavaScript from a CDN, use

   integrity

   attributes to verify the script has not been tampered with.

<script
  src="https://cdn.example.com/lib.js"
  integrity="sha384-abc123..."
  crossorigin="anonymous"
></script>

10. Keep Node.js itself updated. The runtime has its own vulnerability history. Use LTS versions and update when security patches are released.

Details

Supply chain attack vectors:

• Typosquatting:

  lodas

  instead of

  lodash

  — a malicious package with a similar name
• Dependency confusion: A public package with the same name as an internal package — npm may pull the public one
• Maintainer compromise: Legitimate package maintainer's account is hacked (e.g., event-stream incident)
• Malicious postinstall scripts: Code runs during

  npm install

  before you ever import the package

Dependency confusion prevention: Use scoped packages (

@company/utils

), configure

.npmrc

to point to your private registry for scoped packages, and use

npm-package-arg

to detect resolution anomalies.

# .npmrc
@company:registry=https://npm.company.com/

SBOM (Software Bill of Materials): Generate an SBOM for compliance and audit trails. Use

cyclonedx-npm

or

spdx-sbom-generator

to produce machine-readable dependency inventories.

When to accept audit findings: Some vulnerabilities are in dev dependencies that never run in production, or in code paths your application does not exercise. Document accepted risks rather than ignoring them silently.

Common mistakes:

• Ignoring

  npm audit

  output because "everything still works"
• Not committing the lockfile (different installs on different machines)
• Using

  npm audit fix --force

  without reviewing breaking changes
• Installing packages from unverified registries
• Running

  npm install

  in production instead of

  npm ci

  (lockfile not respected)

Source

https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_and_Outdated_Components_Cheat_Sheet.html

Process

1. Read the instructions and examples in this document.
2. Apply the patterns to your implementation, adapting to your specific context.
3. Verify your implementation against the details and edge cases listed above.

Harness Integration

• Type: knowledge — this skill is a reference document, not a procedural workflow.
• No tools or state — consumed as context by other skills and agents.

Success Criteria

• The patterns described in this document are applied correctly in the implementation.
• Edge cases and anti-patterns listed in this document are avoided.