Dependency Management

Dependency Management

Third-party dependencies are simultaneously the most powerful and most dangerous part of modern software. A single mismanaged dependency caused log4shell. Left-pad took down thousands of builds in 11 minutes. Supply chain attacks through dependency confusion hit major enterprises. This skill covers the full lifecycle: choosing, pinning, auditing, updating, and removing dependencies with production discipline.

When to Use

Use for:

• Deciding whether to add a new dependency
• Version pinning strategy (exact vs range vs lockfile-only)
• Setting up automated update workflows (Renovate, Dependabot)
• Security auditing with npm audit, pip audit, Snyk, Socket.dev
• License compliance scanning (MIT/Apache/GPL compatibility)
• Generating Software Bills of Materials (SBOM)
• Resolving peer dependency conflicts and npm overrides
• Responding to security advisories and CVEs
• Detecting typosquatting and dependency confusion attacks

NOT for:

• Internal monorepo package management (use monorepo-management)
• Publishing your own packages to npm, PyPI, crates.io
• Package manager configuration beyond dependency management (workspace config, etc.)
• Vendoring and air-gapped environments (mention these exist but they're outside scope)

---

Core Decision: Should I Add This Dependency?

flowchart TD
    Start[Want to add a dependency?] --> Size{How much code does it replace?}
    Size -->|< 20 lines| Write[Write it yourself]
    Size -->|20-200 lines| Q2{Trivial to implement correctly?}
    Size -->|> 200 lines| Q3{Check the package}

    Q2 -->|Yes, pure logic| Write
    Q2 -->|No, edge cases / locale / timezone| Q3

    Q3 --> Audit{Run audit checks}
    Audit --> Downloads{Weekly downloads?}
    Downloads -->|< 10k| HighRisk[High risk: low adoption]
    Downloads -->|10k-100k| MedRisk[Medium: check actively]
    Downloads -->|> 100k| Maintained{Actively maintained?}

    Maintained -->|Last commit > 2 years| Fork[Consider fork or alternative]
    Maintained -->|Recent commits| License{License compatible?}

    License -->|GPL in proprietary| Reject[REJECT: license issue]
    License -->|MIT / Apache 2.0| Security{npm audit / Socket.dev scan?}

    Security -->|CVEs unfixed| Reject
    Security -->|Clean| Transitive{Transitive dep count?}

    Transitive -->|> 50 new deps| Reconsider[Reconsider: high blast radius]
    Transitive -->|< 50 new deps| Accept[Add with pinned version]

    HighRisk --> Fork
    MedRisk --> Maintained

---

Version Pinning Strategy

Semver Semantics Recap

^1.2.3  = >= 1.2.3, < 2.0.0   (minor + patch updates allowed)
~1.2.3  = >= 1.2.3, < 1.3.0   (patch updates only)
1.2.3   = exactly 1.2.3        (locked)
*       = any version           (never use)

When to Use Each

Anti-Pattern: Caret in Production App Dependencies

Novice: "I use ^ so I always get bug fixes automatically. That's safer." Expert: Caret ranges mean any breaking-within-semver change installs without your knowledge. Semver is aspirational, not enforced — packages regularly ship breaking changes in minor versions. Your lockfile prevents this on developer machines, but CI environments that run npm install instead of npm ci will silently upgrade. Pin your direct dependencies exactly and let the lockfile manage transitive deps. Review updates deliberately via Renovate or Dependabot PRs. Detection: Check package.json for ^ prefixes on runtime dependencies in production apps. Run npm ci on a fresh clone and compare the installed tree to your last deployment.

---

Update Workflow Decision

flowchart TD
    Update[How to handle updates?] --> Auto{Use automation?}
    Auto -->|Yes| Tool{Which tool?}
    Auto -->|No, manual| Manual[Monthly audit: npm outdated / pip list --outdated]

    Tool -->|GitHub repo| Dependabot[GitHub Dependabot]
    Tool -->|Any platform| Renovate[Renovate Bot — more powerful]

    Dependabot --> DConfig[Configure .github/dependabot.yml]
    Renovate --> RConfig[Configure renovate.json]

    DConfig --> DGroup{Group updates?}
    RConfig --> RGroup{Group updates?}

    DGroup -->|Yes| DGrouped[Group patch updates together]
    DGroup -->|No| DPR[One PR per dependency]
    RGroup -->|Yes| RGrouped[Group by type: devDeps patch / prod minor]
    RGroup -->|No| RPR[One PR per dependency]

    RGrouped --> AutoMerge{Automerge safe?}
    DGrouped --> AutoMerge

    AutoMerge -->|Dev deps + patch only| EnableAM[Enable automerge with test gate]
    AutoMerge -->|Prod deps, major versions| RequireReview[Require human review]

---

Security Auditing

The Audit Stack

Run these in sequence from fastest/free to deepest:

# 1. npm audit (built-in, free, fast — checks known CVEs)
npm audit
npm audit --audit-level=high    # Only high+ severity
npm audit fix                   # Auto-fix where possible
npm audit fix --force           # ⚠️ May break API — review first

# 2. pip audit (Python equivalent)
pip install pip-audit
pip-audit
pip-audit --fix                 # Write fixed requirements.txt

# 3. Socket.dev (supply chain analysis beyond CVEs)
npx socket check                # Checks for malicious behavior, typosquatting

# 4. Snyk (deeper analysis, CI integration)
npx snyk test
npx snyk monitor                # Continuous monitoring

# 5. SBOM generation (for compliance)
npx @cyclonedx/cyclonedx-npm --output-format json > sbom.json
# Python: pip install cyclonedx-bom && cyclonedx-py -p

Anti-Pattern: Ignoring Security Advisories

Novice: "The audit shows vulnerabilities but they're in dev dependencies or unused code paths. Not a risk." Expert: Dev dependencies reach production in two ways: (1) build tools that process production code can be compromised, and (2) the advisory may be rated "dev-only" but the package is actually in your production bundle. Check with npm ls <package> to trace the dependency chain. For genuinely dev-only packages (mocha, jest, eslint), moderate severity advisories can be deferred. Critical/high severity — even in dev deps — should be resolved within your SLA. "Not a risk" is an assessment, not a skip; document it. Detection: Run npm audit --production to scope to production-only deps. Check npm ls <vulnerable-pkg> to see all consumers.

---

Supply Chain Security

Typosquatting Detection

Common attack patterns:

• lodash → 1odash (digit 1 instead of letter l)
• express → expres (missing character)
• react → React (capitalization — case-sensitive registries)
• @org/package → org-package (scope confusion)

# Socket.dev catches most of these
npx socket check

# Manual: verify before install
npm view <package-name>         # Check metadata: author, description, repo URL
npm view <package-name> repository  # Verify GitHub repo matches official source

Dependency Confusion Attack

An attacker publishes a public package with the same name as your private @org/package. The package manager fetches the public one because it has a higher version number.

Prevention:

# npm: Use .npmrc scoped registry config
@your-org:registry=https://your-private-registry.example.com

# Or set resolutions/overrides to lock the source
# package.json:
{
  "overrides": {
    "@your-org/internal-package": "npm:@your-org/internal-package@^1.0.0"
  }
}

Lockfile Integrity

# Never commit node_modules — commit only the lockfile
# Verify lockfile integrity after pulls
npm ci                          # Fails if lockfile doesn't match package.json
                                # NEVER use npm install in CI

# Python: use pip-compile for deterministic locks
pip install pip-tools
pip-compile requirements.in     # Generates pinned requirements.txt
pip-sync requirements.txt       # Install exactly this

---

License Compliance

Compatibility Matrix

# Scan all licenses in your dependency tree
npx license-checker --production --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;0BSD"
npx license-checker --production --failOn "GPL;AGPL"

# Python
pip install pip-licenses
pip-licenses --format=markdown --order=license

Anti-Pattern: Excessive Dependencies for Trivial Functionality

Novice: npm install is-odd (actual package, 54M weekly downloads). Installs a package with 1 line of code: n % 2 !== 0. Expert: The left-pad incident (2016) proved that trivial utility packages are operational liabilities. Every production dependency is: a potential CVE vector, a supply chain attack surface, a semver conflict source, and a cognitive load item. Before adding a package, paste the README into ChatGPT and ask "is the core functionality < 20 lines?" For date manipulation, string utilities, and math operations, write the function. For localization, cryptography, protocol parsing — use battle-tested libraries. Detection: Run npx cost-of-modules or check npm page for source code size. Packages under 10KB for non-trivial domains are almost always replaceable. Timeline: Post-left-pad (2016) the ecosystem became more aware of this, but the pattern persists. In 2024 the polyfill.io CDN compromise showed this applies to CDN dependencies too.

---

npm Overrides and Resolutions

Use to fix vulnerable transitive dependencies when the direct dependency hasn't updated:

// package.json — npm overrides (npm 8.3+)
{
  "overrides": {
    "semver": ">=7.5.2",           // Force minimum version across all deps
    "lodash": "4.17.21",           // Force exact version
    "vulnerable-pkg": {
      "sub-dependency": "^2.0.0"   // Scoped: only for this parent
    }
  }
}

// package.json — yarn/pnpm resolutions
{
  "resolutions": {
    "semver": ">=7.5.2"
  }
}

Caution: Overrides can break packages that genuinely require the older API. Always run your test suite after adding overrides.

---

Peer Dependencies

# Check what peer deps a package needs
npm info <package> peerDependencies

# npm 7+ auto-installs peer deps (may surprise you with version conflicts)
# Opt out: npm install --legacy-peer-deps (last resort)

# Check for peer dep conflicts
npm install 2>&1 | grep "peer dep"
npm ls 2>&1 | grep "WARN" | grep "peer"

Rule: If you see peer dependency warnings, don't silence them. They indicate version mismatches that may cause subtle runtime failures. Resolve by pinning the common peer to a compatible version.

---

References

• references/update-strategies.md — Consult for Renovate vs Dependabot configuration details, grouping strategies, automerge policies, and testing update PRs safely
• references/security-auditing.md — Consult for npm audit / Snyk / Socket.dev deep dives, SBOM generation, license scanning tools, and CI integration patterns

Security Auditing for Dependencies

Comprehensive guide to dependency security: tools, workflows, CI integration, SBOM generation, and license scanning. This is the operational layer on top of the security overview in SKILL.md.

---

Tool Landscape

npm audit

Built into npm; checks against npm's advisory database (which sources from NVD and GitHub Security Advisories).

# Basic audit
npm audit

# JSON output (for parsing)
npm audit --json

# Only show high and critical
npm audit --audit-level=high

# Audit only production deps (skip devDependencies)
npm audit --omit=dev

# Auto-fix safe updates
npm audit fix

# Force updates even if semver-incompatible
# ⚠️ Reviews required — can change APIs
npm audit fix --force

# Audit a specific package
npm audit --json | jq '.vulnerabilities | to_entries[] | select(.value.via[].name == "lodash")'

Understanding audit severity:

• Critical (CVSS 9.0+): Exploitable remotely, fix immediately
• High (CVSS 7.0-8.9): Serious; fix within your SLA (usually < 7 days)
• Moderate (CVSS 4.0-6.9): Contextualize; may not be exploitable in your use case
• Low (CVSS 0.1-3.9): Document and defer; fix in next maintenance window

pip-audit (Python)

pip install pip-audit

# Audit current environment
pip-audit

# Audit a requirements file
pip-audit -r requirements.txt

# JSON output
pip-audit --format=json

# Fix fixable vulnerabilities
pip-audit --fix

# Skip specific advisory (with justification documented)
pip-audit --ignore-vuln GHSA-xxxx-xxxx-xxxx

Snyk

Deeper than npm audit: checks transitive deps, provides fix PRs, monitors continuously.

# Install
npm install -g snyk

# Authenticate
snyk auth

# Test (shows vulnerability tree)
snyk test

# Test only production dependencies
snyk test --production

# Monitor this project (creates ongoing monitoring)
snyk monitor

# Fix vulnerabilities (creates PR)
snyk fix

# Test Docker image
snyk container test myimage:latest

# Test IaC files (Terraform, K8s YAML)
snyk iac test .

# JSON output for CI
snyk test --json | jq '.vulnerabilities[] | {id, severity, packageName, title}'

Snyk CI Integration (GitHub Actions):

- name: Run Snyk
  uses: snyk/actions/node@master
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
  with:
    args: --severity-threshold=high --fail-on=all

Socket.dev

Goes beyond CVEs to detect malicious behavior in packages before they become CVEs:

# Install
npm install -g @socketsecurity/cli

# Check a package before installing
npx socket check lodash@4.17.21

# Check entire project
npx socket check

# Real-time monitoring (CI)
npx socket ci --strict

What Socket detects that npm audit misses:

• Packages with hidden network calls
• Packages that install binaries
• Obfuscated code
• Newly published packages with suspicious patterns
• Install scripts that run shell commands
• Packages abandoned but recently transferred to new (unknown) owners
• Typosquatting variations

Socket Scam/Attack Detection Categories:

---

CI Security Gate Integration

GitHub Actions Pattern

# .github/workflows/security.yml
name: Security Audit

on:
  push:
    branches: [main]
  pull_request:
  schedule:
    - cron: '0 8 * * 1'  # Weekly Monday morning

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

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: npm audit (high and above)
        run: npm audit --audit-level=high --omit=dev

      - name: Socket.dev check
        run: npx socket check --strict
        env:
          SOCKET_TOKEN: ${{ secrets.SOCKET_TOKEN }}

      - name: License check
        run: |
          npx license-checker --production \
            --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;0BSD;Unlicense;CC0-1.0" \
            --failOn "GPL;AGPL;LGPL;CC-BY-SA"

Pre-commit Hook for Local Scanning

# .git/hooks/pre-commit (or lefthook / husky)
#!/bin/sh

# Run npm audit on staged changes (only if package.json changed)
if git diff --cached --name-only | grep -q "package"; then
  echo "Running security audit..."
  npm audit --audit-level=critical
  if [ $? -ne 0 ]; then
    echo "Critical security vulnerabilities found. Fix before committing."
    exit 1
  fi
fi

---

SBOM Generation

Software Bill of Materials: a machine-readable list of all components in your software. Required for some compliance frameworks (FedRAMP, SOC 2 Type II, DOD CMMC) and increasingly expected by enterprise customers.

CycloneDX (Recommended Format)

# Node.js
npm install -g @cyclonedx/cyclonedx-npm
cyclonedx-npm --output-format json > sbom.json
cyclonedx-npm --output-format xml > sbom.xml

# Python
pip install cyclonedx-bom
cyclonedx-py environment -o sbom.json
cyclonedx-py requirements -i requirements.txt -o sbom.json

# Rust
cargo install cargo-cyclonedx
cargo cyclonedx

# Go
go install github.com/CycloneDX/cyclonedx-gomod/cmd/cyclonedx-gomod@latest
cyclonedx-gomod app -output sbom.json .

# Docker image SBOM
docker sbom myimage:latest --format cyclonedx
# or
syft myimage:latest -o cyclonedx-json=sbom.json

SPDX Format

# Node.js
npx spdx-sbom-generator

# Using Syft (supports all languages + Docker)
brew install syft
syft . -o spdx-json=sbom.spdx.json
syft myimage:latest -o spdx-json=container-sbom.spdx.json

SBOM in CI

- name: Generate SBOM
  run: |
    npx @cyclonedx/cyclonedx-npm --output-format json > sbom.json

- name: Upload SBOM as artifact
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.json
    retention-days: 90

- name: Scan SBOM for vulnerabilities
  run: |
    # Use Grype to scan the SBOM
    curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
    grype sbom:sbom.json --fail-on high

---

License Scanning

license-checker (Node.js)

npm install -g license-checker

# List all licenses
license-checker --production

# Check against allowed list
license-checker --production --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC;0BSD"

# Fail on prohibited licenses
license-checker --production --failOn "GPL-2.0;GPL-3.0;AGPL-3.0"

# Output as CSV for compliance team
license-checker --production --csv > licenses.csv

# Output as JSON for tooling
license-checker --production --json > licenses.json

# Exclude packages (for known exceptions, document why)
license-checker --production \
  --excludePackages "exception-package@1.0.0" \
  --onlyAllow "MIT;Apache-2.0"

pip-licenses (Python)

pip install pip-licenses

# Summary table
pip-licenses

# Markdown output
pip-licenses --format=markdown

# Check for prohibited licenses
pip-licenses --fail-on "GPL;AGPL"

# Full detail including project URLs
pip-licenses --with-urls --with-description

# Generate requirements file with license info
pip-licenses --format=json > licenses.json

License Compatibility Reference

Your project type → Dependency license:

Proprietary/Commercial:
  MIT        → OK (keep attribution in NOTICE)
  Apache-2.0 → OK (keep attribution + NOTICE file)
  BSD-*      → OK (keep attribution)
  ISC        → OK
  LGPL-2.1   → OK if dynamically linked (check usage)
  LGPL-3.0   → OK if dynamically linked (check usage)
  GPL-2.0    → REJECT (copyleft spreads to your code)
  GPL-3.0    → REJECT
  AGPL-3.0   → REJECT (network use triggers copyleft)
  CC-BY-SA   → REJECT (share-alike applies)

Open Source (MIT/Apache):
  All of the above → OK (your license is permissive)
  GPL → OK (but check if you want to maintain GPL compatibility)

Open Source (GPL):
  MIT, Apache, BSD → OK (permissive absorbs into GPL)
  LGPL → OK
  GPL-2.0 → Check: must be same version or "later"
  GPL-3.0 → If your code is GPL-2.0-only, this is incompatible
  AGPL → Compatible but adds network copyleft

Dual-licensed packages: Some packages (like MySQL Connector) offer commercial licenses for proprietary use. Check the package README carefully.

---

Dependency Confusion Attack Prevention

This is a supply chain attack where an attacker publishes a public package with the same name as your private package. The package manager uses the public version because its version number is higher.

npm Prevention

# .npmrc — scope all internal packages to private registry
@your-org:registry=https://your-private-registry.example.com

# Authenticate
npm login --scope=@your-org --registry=https://your-private-registry.example.com

# package.json — add "publishConfig" to internal packages
{
  "name": "@your-org/internal-lib",
  "publishConfig": {
    "registry": "https://your-private-registry.example.com"
  }
}

Detect Potential Confusion

# Check if your private package name is claimed on public npm
npm view @your-org/internal-package 2>&1 | grep "404"
# If you get output instead of 404, the name is already taken publicly

Reserve Your Package Names

Proactively publish placeholder packages on public npm for any private package names:

{
  "name": "@your-org/internal-package",
  "version": "0.0.1",
  "description": "This package is for internal use only. If you received this as a dependency, you have a misconfiguration.",
  "main": "index.js",
  "publishConfig": {
    "access": "public"
  }
}

---

Vulnerability Triage Workflow

When audit reveals vulnerabilities:

flowchart TD
    Alert[Vulnerability alert received] --> Severity{Severity?}
    Severity -->|Critical| Immediate[Fix within 24h]
    Severity -->|High| Week[Fix within 7 days]
    Severity -->|Moderate/Low| Assess[Assess exploitability]

    Assess --> Exploit{Exploitable in our context?}
    Exploit -->|Yes| Week
    Exploit -->|No| Document[Document + defer to next maintenance]

    Immediate --> FixPath{Fix available?}
    Week --> FixPath
    FixPath -->|npm audit fix works| AutoFix[Apply auto-fix + test]
    FixPath -->|Override needed| Override[Add override in package.json]
    FixPath -->|No fix yet| Mitigate[Find alternative or mitigate usage]
    FixPath -->|False positive| FP[Mark as false positive + document]

    AutoFix --> TestSuite[Run full test suite]
    Override --> TestSuite
    Mitigate --> TestSuite
    TestSuite -->|Pass| Merge[Merge and deploy]
    TestSuite -->|Fail| Debug[Debug regression]

Documenting Accepted Risks

When you defer or accept a vulnerability, document it:

// .nsprc or audit-exceptions.json
{
  "exceptions": [
    {
      "id": "GHSA-xxxx-xxxx-xxxx",
      "package": "some-package",
      "severity": "moderate",
      "reason": "Only used in test suite, never in production build. Dev-only dependency.",
      "expires": "2026-06-01",
      "reviewer": "your-name",
      "reviewed": "2026-03-01"
    }
  ]
}

This creates an audit trail and forces re-review when the exception expires.

---

Security Monitoring Checklist

Weekly:

• [ ] Run npm audit / pip-audit in CI
• [ ] Check Dependabot / Renovate security PRs
• [ ] Review GitHub Security tab for new advisories

Monthly:

• [ ] Run Socket.dev full scan
• [ ] Regenerate SBOM and archive it
• [ ] Review license compliance report

Quarterly:

• [ ] Audit for unused dependencies (npx depcheck)
• [ ] Check packages with no recent activity (potential abandonment)
• [ ] Review and update audit exception list (expire stale entries)
• [ ] Update base Docker images to latest patch versions

On incident:

• [ ] Immediately: identify scope (which services, which versions)
• [ ] Within 1h: apply override or pin to safe version
• [ ] Within 24h: deploy fix to production
• [ ] Within 72h: post-mortem and process improvement

Dependency Update Strategies

Automated dependency updates are table stakes for production software. The question isn't whether to automate — it's how to configure automation so it helps without drowning your team in PRs.

---

Renovate vs Dependabot

Recommendation: Use Renovate for any project where you want fine-grained control. Use Dependabot if you just want GitHub's built-in security alerting with minimal config.

---

Renovate Configuration

Starter Config

// renovate.json
{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended"
  ],
  "timezone": "America/New_York",
  "schedule": ["before 9am on Monday"],
  "packageRules": [
    {
      "matchUpdateTypes": ["patch", "pin", "digest"],
      "matchPackagePatterns": ["*"],
      "automerge": true,
      "automergeType": "pr",
      "platformAutomerge": true
    },
    {
      "matchUpdateTypes": ["minor"],
      "matchDepTypes": ["devDependencies"],
      "groupName": "dev dependency minor updates",
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true
    }
  ]
}

Grouping Strategies

Group updates to reduce PR noise:

{
  "packageRules": [
    {
      "matchPackagePatterns": ["^@types/"],
      "groupName": "DefinitelyTyped",
      "automerge": true
    },
    {
      "matchPackagePatterns": ["eslint", "prettier", "^@typescript-eslint"],
      "groupName": "linting and formatting",
      "automerge": true
    },
    {
      "matchPackagePatterns": ["vitest", "jest", "testing-library"],
      "groupName": "testing framework",
      "automerge": false
    },
    {
      "matchPackagePrefixes": ["@aws-sdk/"],
      "groupName": "AWS SDK",
      "automerge": false
    },
    {
      "matchPackagePrefixes": ["react", "@react"],
      "groupName": "React ecosystem",
      "automerge": false
    }
  ]
}

Automerge Policy

Safe to automerge (after tests pass):

• All patch updates for non-critical packages
• Dev-dependency minor updates (formatters, linters, type definitions)
• Lockfile-only updates (no version change)

Require human review:

• All major version bumps
• Production dependency minor/major changes
• Any security-flagged update (review the fix, not just merge it)
• Framework core packages (React, Next.js, Vue, etc.)

{
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "excludePackagePatterns": ["express", "fastify", "koa", "next", "react"],
      "automerge": true,
      "automergeType": "branch"   // "branch" merges without PR; "pr" creates PR
    },
    {
      "matchUpdateTypes": ["major"],
      "labels": ["dependencies", "major-update"],
      "assignees": ["your-github-username"],
      "automerge": false
    }
  ]
}

Testing Strategy for Update PRs

Never automerge without a CI gate. Your CI pipeline for dependency PRs should:

1. Unit tests: Catch obvious breakage (changed APIs, removed exports) 2. Integration tests: Catch subtle breakage (behavior changes, protocol changes) 3. Type check: tsc --noEmit catches type-level API breaks 4. Build check: npm run build catches bundler and resolution issues 5. Security rescan: Run npm audit on the PR branch — the update may itself introduce a CVE

For major version bumps, add a checklist:

## Major Version Review Checklist
- [ ] Read CHANGELOG / BREAKING CHANGES section
- [ ] Check if any of our usage patterns are deprecated
- [ ] Run full test suite manually
- [ ] Check transitive dependency changes (`npm ls <package>`)
- [ ] Verify Docker build still works
- [ ] Test in staging for 24h before merging

---

Dependabot Configuration

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
      time: "09:00"
      timezone: "America/New_York"
    open-pull-requests-limit: 10
    groups:
      dev-dependencies:
        dependency-type: "development"
        update-types:
          - "minor"
          - "patch"
      production-patches:
        dependency-type: "production"
        update-types:
          - "patch"
    ignore:
      - dependency-name: "some-broken-package"
        versions: ["2.x"]
    labels:
      - "dependencies"
    reviewers:
      - "your-github-username"

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    ignore:
      - dependency-name: "*"
        update-types: ["version-update:semver-major"]

  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"

Dependabot Auto-Merge via GitHub Actions

# .github/workflows/dependabot-automerge.yml
name: Dependabot auto-merge
on: pull_request

permissions:
  contents: write
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"

      - name: Auto-merge patch/minor dev deps
        if: |
          steps.metadata.outputs.update-type == 'version-update:semver-patch' ||
          (steps.metadata.outputs.update-type == 'version-update:semver-minor' &&
           steps.metadata.outputs.dependency-type == 'direct:development')
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{ github.event.pull_request.html_url }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

---

Update Cadence Recommendations

---

Stale Dependency Audit

Run quarterly to find dependencies that should be removed:

# Find unused dependencies (Node)
npx depcheck

# Find packages with no updates in > 1 year
npm outdated --long 2>/dev/null | awk 'NR>1 {print $1}' | while read pkg; do
  info=$(npm view $pkg time.modified 2>/dev/null)
  echo "$pkg: $info"
done

# Find large packages (size audit)
npx cost-of-modules

# Python: check for unused imports and packages
pip install pigar
pigar generate  # Regenerates requirements from imports

---

Handling Update Failures

When a dependency update breaks tests:

1. Check the CHANGELOG for the version that broke things 2. Search GitHub issues for "v2.0.0 breaking" or the symptom 3. Pin to the last working version in the short term:

   // renovate.json: ignore this version
   { "ignoreDeps": ["broken-package"] }

   // package.json: pin explicitly
   { "overrides": { "broken-package": "1.99.0" } }

4. Open an issue with the upstream maintainer if it's a regression 5. Schedule a migration for the breaking change; don't ignore it indefinitely

---

Language-Specific Notes

Python

• Use pip-compile (pip-tools) to generate pinned requirements.txt from requirements.in
• pip-sync installs exactly the pinned set (removes extras)
• Renovate supports Python pip, poetry, pipenv, pdm, uv
• uv lock generates uv.lock — use uv sync --frozen in CI

Rust

• Cargo.lock is committed for binaries, .gitignored for libraries
• cargo update updates within SemVer constraints
• cargo audit checks for CVEs in crates.io

Go

• go.sum is the lockfile equivalent — always commit it
• go get -u ./... updates all deps; risky for major version jumps
• govulncheck ./... for CVE scanning (official Go tool)

Java/Maven

• versions:use-latest-releases plugin for updates
• OWASP Dependency Check plugin for CVEs
• Dependabot supports maven ecosystem