Dependency updates are reliability work, not maintenance work

The pattern

Batch update model (risky):   Continuous model (safe):

Q1: Skip                      Week 1: +2 deps (auto-PR)
Q2: Skip                      Week 2: +1 dep (auto-PR)
Q3: Skip                      Week 3: +3 deps (auto-PR)
Q4: "Upgrade sprint"          ...
    6-version jumps            Each PR: small diff, fast review
    Breaking changes           Rollback: one PR revert
    3-day debugging session    MTTR if it breaks: 10 min

The insight

The orgs that get hit hardest by CVEs and supply chain incidents have one thing in common: they batch dependency updates into quarterly sprints. By then, the update is a 6-version jump, the changelog is 200 lines, and the 'quick upgrade' becomes a multi-day incident waiting to happen.

The non-obvious part

Automated dependency PRs (Renovate/Dependabot) with a 2-week merge SLA cost almost nothing — a 5-minute review per PR. Skipping them accumulates a compounding tax: more conflicts, larger blast radius, slower rollback. The math strongly favors continuous updates.

My rule

→ Automate dependency PRs. Set a team policy: merge or explicitly defer within 2 weeks. Every skip is a known risk you're consciously accepting — treat it that way.

Worth reading

• ▸ Renovate Bot — automerge strategies, scheduling, and grouping (docs.renovatebot.com)
• ▸ SLSA framework — supply chain integrity levels and provenance (slsa.dev)