Ask the demo to open a real fix pull request against one of your repositories, then let your own CI run on it. A fix is only a fix if it builds, passes your tests, and changes only the lines it should. A suggested version number alone proves none of that.
What "fix available" can mean
The phrase hides three very different claims:
- A newer version of the package exists.
- A newer version exists and resolves a known advisory.
- A pull request has been prepared, built and tested against your project.
Many tools stop at the first or second. Only the third saves your developers time. In the demo, ask which of the three you are looking at.
The pull request test
- Choose a finding with a suggested fix. Pick it yourself.
- Ask the tool to open a pull request in a test branch or a fork, not on your main branch.
- Wait for your own CI to run. Do not accept the vendor's own test report as a substitute.
- Read the diff. Count the files changed.
- Check the PR description for what was changed and why.
What to look for in the diff
| Item | Expected | Concern |
|---|---|---|
| Files changed | The manifest and the lockfile | Unrelated formatting changes |
| Version jump | Smallest change that resolves the advisory | A major version leap with no note |
| Lockfile | Regenerated cleanly | Hand edited or partial |
| Description | Names the advisory and the old and new versions | Generic text |
A major version bump can be legitimate, but it can break callers. The description should flag it so reviewers know to look closer.
Tests are the real check
Your CI is the judge. If your test suite is thin, a green build says little. Be honest about that, and consider adding one or two tests around the area the dependency touches before you rely on automated fixes at scale.
Also ask what happens when the build fails. Does the tool retry, report the failure, or close the PR quietly? A good tool tells you plainly.
Questions about control
Automation is useful only when you decide how far it goes. Ask:
- Can fix pull requests be turned off per repository or per category?
- Who must approve before merge?
- Can it be set to propose only, never merge?
- Is there a log of what it opened and why?
If the answer to the second question is "nobody", look elsewhere.
Where Safeguard fits
Safeguard offers autonomous remediation with fix pull requests. It is off by default, and every category starts on Manual, so nothing is proposed until you choose. The demo below shows the fix-available view.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice what information appears before a fix is proposed, and what you would still need to check in your own CI.
Quick check
Should I merge a green fix pull request without reading it?
No. Green means your tests passed. A human should still read the diff, especially for major version changes.
What if the fix breaks my build?
Record it as a result. Ask the vendor how often that happens in their own data and what the tool does next.
Last reviewed: 19 October 2026.
