Automate the fixes that are frequent, low risk and easy to verify: patch version bumps in services with strong tests. Move up to minor bumps once those run cleanly. Keep major upgrades, code changes and no-fix cases with people. Expand one class at a time, based on your own results.
Why a ladder instead of a switch
Remediation capacity grows when routine work stops consuming engineer hours. But automation that opens a bad change costs more than it saves, because it burns reviewer trust. A ladder lets you earn trust in steps, with evidence at each rung.
Google's SRE guidance describes toil as work that is manual, repetitive and automatable, and that scales with the service. Routine dependency bumps match that description closely, which is why they are the natural starting point.
The ladder
| Rung | Fix class | Automation stance | What proves it is safe |
|---|---|---|---|
| 1 | Patch bump, tests strong | Open pull request automatically, human merges | Several weeks of green merges |
| 2 | Patch bump, tests weak | Open pull request, add test work first | Test gaps closed |
| 3 | Minor bump | Open pull request with release notes summary | Low revert rate on rung 1 |
| 4 | Transitive override | Open pull request, human reviews closely | Reviewers understand lock file diffs |
| 5 | Auto merge on green for rung 1 | Optional, only after long clean record | Rollback tested |
| 6 | Major upgrade or code change | People lead, tools assist | Not a candidate for hands-off |
| 7 | No fixed version | People decide: mitigate, replace, accept | Decision, not automation |
Rung 5 is optional. Many teams stay at human merge permanently, and that is a sound choice.
What to check before each step up
- Look at the revert and rollback count for the rung below. If it is not near zero, stay put.
- Confirm CI covers the paths the dependency touches. A green build over thin tests proves little.
- Check that reviewers can see what changed. Lock file diffs need a readable summary.
- Confirm who owns a failure. A bot's pull request that breaks a build should page the owning team, not the security group.
- Keep a documented way to turn a class off.
Starting in report-only mode
Before opening real pull requests, some teams run in a report-only mode: the tool proposes what it would change, and people compare that with what they would have done. See shadow mode for automated remediation for the approach.
Measuring the capacity effect
Track hands-on hours per fixed finding for each rung. The saving shows up as fewer reviewer minutes per fix, not fewer reviewers. Release that time to the classes that need it, such as major upgrades.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which findings show a fixed version available. Those are the candidates for the lower rungs of the ladder.
Where Safeguard fits
Safeguard's autonomous remediation is off by default and every category starts on Manual. You choose which fix classes may open pull requests, and the changes go through your normal review. That matches the ladder: start small, widen on evidence.
Quick check
Should automated fixes merge without review?
Not at first. Begin with human merge. Consider auto merge only for a narrow class with a long clean record and a tested rollback.
What if our tests are thin?
Improve tests for the services that matter most before automating there. Automation over weak tests moves risk, not removes it.
Sources
Last reviewed: 19 October 2026.
