A dependency fix should wait for a human when the update crosses a major version, touches code on the main request path, lacks test coverage, affects data handling, or has no clear owner. Any one of these signals is enough to keep the PR on manual approval until you resolve it.
The principle
Automation suits changes that are boring, well tested and easy to undo. The five signals below point at the opposite. They are not a complete list, so add your own after incidents.
Signal 1: a major version jump
Semantic versioning says a major release may contain breaking changes. Renovate's example config skips automerge for packages whose current version starts with zero because pre 1.0.0 releases can change in breaking ways at any time. The same caution applies to major bumps. A fix that arrives only in a new major release is often a migration project, not a routine update. See can a security fix be a breaking change in semver.
Signal 2: the package sits on a critical path
Authentication, payment, parsing of untrusted input, cryptography and serialization deserve eyes. A small change in these areas can have large effects. Keep them manual even when the update is a patch.
Signal 3: the tests do not cover it
If you cannot name a test that would fail if the package misbehaved, the green check is empty. Add a test, or hold the update until a person has exercised the behaviour. See what a test gate on a fix PR cannot catch.
Signal 4: data is involved
Database drivers, ORMs, message formats and file parsers can change what is written. Rolling back code does not undo bad writes. Treat these as manual with a staged rollout.
Signal 5: nobody owns it
No owner means nobody to roll back, nobody to watch the deploy and nobody to answer questions. That is a reason to wait, and a reason to fix ownership.
A quick decision table
| Signal present | Decision |
|---|---|
| None | Candidate for automation after a trial |
| One, and mitigable | Manual approval, with the mitigation recorded |
| Two or more | Manual approval, canary deploy, named watcher |
| Emergency with any signal | Follow the emergency path, with a person leading |
Waiting is not the same as delaying
When a fix waits for a human, give the human a date. A waiting PR with no assignee is how vulnerabilities live for months. Set the approval target for its lane. See how quickly should a person approve a dependency fix PR.
Revisit the signals
Signals change. A package that was critical path may be moved behind an interface. A test gap may be closed. Review the manual list each quarter and move categories toward automation only with evidence from your own trial. See shadow mode for automated remediation: run report only first.
Try it yourself
Open the demo and see how reachability separates findings your code can hit from findings it cannot. Use that to decide which fixes need a person now.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Does a patch release always qualify for automation?
No. A patch release on a critical path package, or without tests, can still deserve a human.
Can a human approve quickly and still be useful?
Yes. A reviewer who checks the evidence and the rollback plan in a few minutes adds real value.
Sources
Last reviewed: 19 October 2026.
