Automatic fixing tools usually open a pull request that bumps a vulnerable package to a patched version, then let your tests decide. They work well for patch and minor upgrades with a clean test suite. They stop where the fix needs a breaking change, a code edit, or a package with no patched release.
The three kinds of automatic fix
Version bump pull requests. The most common. The tool finds a patched version and proposes the change. Low risk, high volume.
Transitive overrides. The vulnerable package is not yours, so the tool pins a safe version through an override or resolution rule. Useful, but it can mask a real incompatibility, so run the full tests.
Code level patches. Some tools propose source edits. These need the most review because the change is not just a version number.
What to ask a vendor
- Does it open a pull request or push directly? Pull request is the safer default.
- Can I set it to do nothing until I approve? Look for per category control.
- What happens when tests fail? Good answer: the pull request is labelled and left for a human.
- Does it explain why a version was chosen?
- Can it say when no fix exists, instead of guessing?
Honest limits
No tool can promise that an upgrade will not change behaviour. Semantic versioning is a convention, not a guarantee. Your test coverage is the real safety net, and thin coverage means more manual review no matter what you buy.
When free is enough
If your stack is one ecosystem and you mainly need patch bumps, a built in update bot plus required CI checks does most of the work. Paid tools earn their place with many repositories, mixed languages, policy needs, or when you want fix suggestions that account for reachability.
Measuring whether it works
Track four numbers for a month: fix pull requests opened, share merged without edits, share reverted, and median time from detection to merge. If the merged share is low, the tool is creating review work. If reverts are high, your tests are not catching breakage or the tool is too aggressive for your codebase. Adjust scope before you widen it.
Keep a note of the changes that needed manual work. They show where your real remediation effort sits, and that list is useful whichever tool you pick.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a fix is presented as a reviewable change rather than an applied one.
Where Safeguard fits
Safeguard offers autonomous remediation with fix pull requests. It is off by default, and every category starts on Manual. You can scan a repository for free to see what would be proposed.
Quick check
Should fixes merge automatically?
Start with review required. Consider auto merge later, only for low risk categories with strong tests.
Last reviewed: 19 October 2026.
