📦 Dependency Upgrade Strategist

Dependency Upgrade Strategy: Next.js + tRPC SaaS

Diagnosis

Three concrete issues:

1. No upgrade discipline → 6-month deferred maintenance + CVE backlog.

2. Major framework drift (Next.js 14 → 15 is non-trivial). Each month deferred = harder upgrade.

3. No automation tooling. Reviewing 40 dep updates manually is unsustainable; that's why nothing happens.

Highest-leverage fixes:

1. Set up Renovate for the dev-test + library tiers (auto-merge after CI). ~80% of dep work goes away.

2. Triage the 12 CVEs in 1 day. Most likely 8-10 are not exploitable in your context (server-only deps, etc.); document. Fix the actual exploitable ones.

3. Plan Next.js 14 → 15 as an ADR-worthy migration. 1-2 weeks of work, staged. Don't just `npm install next@latest`.

4. Establish quarterly cadence going forward. Prevents 6-month stale debt repeating.

Estimated outcome: dep work drops from 'whoever has time someday' to ~2hrs/sprint sustained. SOC 2 SBOM + vuln tracking ready by Q3.

Dependency Tiers

Tier 1: Critical (auto-pin, manual upgrade with ADR)

• Next.js, React, Drizzle ORM, NextAuth.js
• Cadence: per major release evaluation; minor upgrades quarterly
• Process: ADR for major; PR with full review for minor

Tier 2: Framework-adjacent (auto-PR, manual review + merge)

• Stripe SDK, OpenAI SDK, Zod, BullMQ, Pino, ZodSchemaValidation
• Cadence: weekly auto-PRs from Renovate; manual review + merge within 1 week
• Process: review changelog, run full test suite, merge if green

Tier 3: Libraries (auto-PR, auto-merge if CI passes for minor/patch)

• date-fns, lodash, classnames, ~150 utility libraries
• Cadence: continuous, auto-merged daily
• Process: Renovate creates PR → CI runs → auto-merge if all green

Tier 4: Dev/Test (auto-PR, auto-merge aggressively)

• ESLint, Vitest, TypeScript tooling, Prettier, build tools
• Cadence: continuous, auto-merged daily even for major
• Process: Renovate creates PR → CI runs → auto-merge
• Risk: low (these don't affect production runtime)

Auto-Upgrade Setup

Renovate config (renovate.json):

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":dependencyDashboard"],
  "timezone": "America/Los_Angeles",
  "schedule": ["every weekend"],
  "prHourlyLimit": 4,
  "prConcurrentLimit": 8,
  
  "packageRules": [
    {
      "description": "Critical deps — manual review only",
      "matchPackagePatterns": ["^next$", "^react$", "^drizzle-orm$", "^next-auth$"],
      "automerge": false,
      "labels": ["deps-critical"],
      "reviewers": ["@tech-leads"],
      "prCreation": "approval"
    },
    {
      "description": "Framework-adjacent — auto-PR, manual merge",
      "matchPackageNames": ["stripe", "openai", "zod", "bullmq", "pino"],
      "automerge": false,
      "labels": ["deps-framework-adjacent"]
    },
    {
      "description": "Libraries minor/patch — auto-merge",
      "matchPackagePatterns": ["^.*$"],
      "matchUpdateTypes": ["minor", "patch"],
      "matchDepTypes": ["dependencies"],
      "automerge": true,
      "automergeType": "branch",
      "labels": ["deps-libraries"]
    },
    {
      "description": "Dev/test deps — auto-merge all (including major)",
      "matchDepTypes": ["devDependencies"],
      "automerge": true,
      "automergeType": "branch",
      "labels": ["deps-dev"]
    },
    {
      "description": "Security updates — high priority",
      "matchUpdateTypes": ["patch"],
      "vulnerabilityAlerts": {
        "enabled": true,
        "prCreation": "immediate"
      }
    }
  ],
  
  "vulnerabilityAlerts": {
    "enabled": true
  },
  
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["every weekend"]
  }
}

This: weekly batch runs over weekends, auto-merge low-risk deps, manual review for critical.

CVE Triage Process

For your 12 high-severity CVEs:

Step 1: Filter by exploitability

npm audit --json > audit.json
# Or with pnpm:
pnpm audit --json > audit.json

For each CVE, ask:

1. Is the dep used at runtime or only in builds? Build-only = lower risk.

2. Is the vulnerability in a code path we use? Library has 50 functions; we use 3 — vulnerability in unused function is N/A.

3. Is the input attacker-controllable? A regex CVE matters if we feed user input through it; not if it's internal.

4. What's the severity in CVSS context? 'High' assumes worst-case; YOUR case may be 'Medium' or 'N/A.'

Step 2: Classify

• Critical (fix this week): vulnerability is exploitable + we use the affected code path + user input flows through it. Examples: prototype pollution in input parser, SSRF in HTTP client.
• Important (fix this sprint): exploitable but limited blast radius. Examples: regex DoS in non-critical path.
• Acknowledge (document, defer): not exploitable in our context. Document reasoning. Reassess if context changes.

Step 3: Document

Maintain a SECURITY.md or vuln-log: 'CVE-2024-XXXX: documented as N/A because we don't expose user input to vulnerable function. Reviewed 2026-04-28 by Sarah Chen.'

For SOC 2: this audit trail is what auditors want to see. NOT 'we ignored it' but 'we evaluated and concluded.'

Tools

• Snyk (free tier OK at your scale) — better context than npm audit
• Socket.dev — better at supply-chain attack detection
• Mend Bolt — free for OSS

Major Upgrade Workflow

For Next.js 14 → 15 (your specific case):

Phase 1: Research (1 day)

• Read the migration guide thoroughly
• Identify breaking changes affecting your code
• Check if you use any deprecated APIs
• Estimate effort

Phase 2: ADR (0.5 day)

• Write ADR documenting the decision
• Trade-offs (cost vs benefit)
• Rollback plan

Phase 3: Branch + upgrade (1-2 days)

• New branch, run codemod (npx @next/codemod@latest)
• Manually fix what codemod misses
• Run full test suite
• Fix any test failures

Phase 4: Staging soak (3-5 days)

• Deploy to staging
• Run for at least 3 business days
• Monitor for runtime errors, performance regressions, edge cases
• Spot-check user flows

Phase 5: Gradual production rollout (1-2 days)

• Deploy to 1 production canary instance
• Monitor 24h
• Roll to 100% if stable

Phase 6: Post-rollout (ongoing)

• Monitor for 1 week
• Document lessons learned
• Update ADR with status

For Drizzle ORM major version upgrade: similar pattern, with extra emphasis on schema-related testing.

For Node major version upgrade: longer staging soak (7+ days). Test memory/perf regressions.

Test Gate Strategy

For any dep upgrade PR:

Must pass before merge:
- Lint (no new lint errors)
- Type-check (no new type errors)
- Unit tests (existing tests still pass)
- Integration tests (existing tests still pass)
- E2E tests (critical user flows work)
- Build (production build succeeds)

For Tier 1+2 deps, also:

• Manual review of changelog
• Spot-check 2-3 known-affected code paths
• Verify behavior unchanged in staging for 48h

For Tier 3+4 deps (auto-merged):

• Trust CI alone
• If a regression slips through, GitHub revert + investigate

Add a 'dep upgrade smoke test':

// /tests/smoke/dep-upgrade.test.ts
// Run on every PR. Quick test that verifies:
// - Server starts
// - DB connection works
// - Stripe SDK loads
// - Critical imports resolve
// Catches catastrophic dep breakage early.

Lockfile + Pinning Strategy

In package.json:

• Tier 1 deps: exact pinning. "next": "15.0.3" (no caret). Major upgrade is intentional.
• Tier 2 deps: caret. "^stripe": "15.2.0". Patches auto-allowed.
• Tier 3+4 deps: caret. Standard.

Always commit pnpm-lock.yaml. Reproducible builds. CI uses pnpm install --frozen-lockfile — fails if lockfile is out of sync.

For SOC 2: lockfile is your audit trail of what's actually installed. Keep it.

Quarterly Transitive Audit

Every 3 months:

# Generate dep tree
pnpm list --depth=Infinity > deps-Q2-2026.txt

# Find anomalies
pnpm audit

# Generate SBOM (for SOC 2)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# Review:
# - Any unmaintained transitive deps? (last commit >2 years ago)
# - Any deprecated transitive deps? (npm marks them)
# - Any net-new high-severity vulnerabilities?
# - Any unfamiliar packages? (supply-chain audit)

For SOC 2 SBOM: generate quarterly, store in compliance evidence folder. Auditor will ask for it.

Supply-chain audit: scan for known-malicious packages (recent npm compromises). Use Socket.dev or similar.

Implementation Plan

Week 1: Triage existing CVE backlog

• Run audit, categorize 12 CVEs into Critical/Important/Acknowledge
• Fix Critical (probably 1-3 of them)
• Document Acknowledge (probably 8-9)

Week 2: Set up Renovate

• Configure Renovate with the rules above
• Enable on the repo
• Let it generate PRs
• Verify auto-merge works for Tier 4 deps
• Manually merge first batch of Tier 3 PRs to validate

Week 3: Catch up Tier 2 deps

• Manually review + merge Tier 2 dep PRs (Stripe SDK, Zod, etc.)
• Run full test suite per merge
• Track any breakages — refine test coverage where gaps exist

Week 4: Plan Next.js 14 → 15 upgrade (ADR phase)

• Read migration guide
• Write ADR
• Schedule the work for an upcoming 2-week sprint

Weeks 5-7: Execute Next.js upgrade (per major upgrade workflow)

Week 8: Establish ongoing cadence

• Document the upgrade discipline in team wiki
• Set up Slack alert for vuln-flag PRs
• Schedule quarterly SBOM generation

Tooling

• Renovate (free for OSS, $19/mo for private repos via Mend): auto-PR generation
• GitHub Dependabot Alerts: free, basic vuln scanning
• Snyk (free tier): better vulnerability context
• Socket.dev: supply-chain attack detection
• CycloneDX npm: SBOM generation
• pnpm audit: built-in dep vuln check
• @next/codemod: framework migration helper

What This Strategy Won't Solve

• Won't auto-fix breaking changes. Codemods help; manual work still required for non-mechanical changes.
• Won't replace test discipline. If your tests don't cover a code path, dep upgrades that break it won't surface.
• Won't compensate for unmaintained deps. Some deps go stale; sometimes you need to fork or replace.
• Won't auto-detect supply-chain attacks until they're known. Defense: minimize deps, prefer well-known maintainers.
• Won't reduce dep count itself. That's a separate effort (audit + remove unused).

Maintenance Cadence

Weekly (auto + 30 min review):

• Renovate runs over weekend; review Monday
• Auto-merged PRs verified
• Manual merge for Tier 2 PRs
• New CVE alerts triaged

Monthly:

• Tier 1 dep status check (any new minor versions to plan?)
• Vuln log review (any acknowledged CVEs that should be re-evaluated?)

Quarterly:

• Transitive audit
• SBOM generation
• Supply-chain scan
• Strategy review (is tooling still right?)

Per Major Upgrade:

• ADR + staged migration per workflow
• Always slot for ~1-2 weeks of work

Key Takeaways

• 4-tier classification: Critical, Framework-adjacent, Libraries, Dev/Test. Different cadence per tier.
• Renovate auto-merges Tier 3 (libraries minor/patch) + Tier 4 (dev/test). Eliminates ~80% of manual dep work.
• CVE triage by exploitability. Most 'high-severity' are N/A in your context — document the reasoning. SOC 2 wants evidence of evaluation, not blanket fixes.
• Major framework upgrades (Next.js 14→15) are ADR-worthy multi-week efforts. Don't npm install next@latest and pray.
• Lockfile committed + frozen in CI. Reproducible builds = SOC 2 compliance + reliable deploys.
• Quarterly transitive audit + SBOM generation. Compliance + supply-chain hygiene.