A finding that includes a concrete fix gets acted on faster, because the developer skips the research step. A good fix suggestion names the exact change, shows the effect on the code, and says what could break. For risky changes, show options and let a person choose.
What is in a useful fix suggestion
| Part | Example for a dependency | Example for code |
|---|---|---|
| The change | Upgrade library from 2.3.1 to 2.3.9 | Replace string concatenation with a parameterized query |
| The scope | Direct dependency in the service manifest | Lines 38 to 44 of the data layer |
| The effect | Closes 3 findings | Removes the injection path |
| The risk | Patch release, no API change noted | Query helper signature changes |
| The check | Run the existing tests | Add a test with a quote character in the input |
Without the risk line, a developer has to guess whether the change is safe. Guessing slows everyone down and sometimes ends in a rollback.
Three levels of help
Level 1: advice. Text that says what to change. Cheap to produce and easy to ignore.
Level 2: a suggested edit. A diff the developer can apply in the editor or on the pull request. Faster, but still needs review.
Level 3: a prepared pull request. The change, the tests run, and the description are ready. The developer reviews and merges. This is the most helpful and the most important to keep under human control.
Where a person must decide
Not every fix is safe to automate. Treat these as decisions, not suggestions.
- Major version upgrades with breaking changes.
- Changes to authentication, authorization or cryptography.
- Fixes that touch public APIs.
- Anything that alters data or schemas.
See the fix pull request reviewer checklist for what a reviewer should check before merging a generated change.
What if there is no fix
Sometimes none exists. Say so plainly and offer the next best action: a mitigation, a way to remove the vulnerable path, a note to check back on a date, or an alternative package. "No fix available" with no action is the kind of message that teaches people to ignore findings.
Measure it
Compare time to close for findings with a fix suggestion against those without. If the gap is small, your suggestions may be too vague or too risky to trust. If the gap is large, expand them to more rules.
Keep suggestions honest
Do not present a guess as a certain fix. Mark confidence, show what was tested, and link to the advisory. Wrong confident suggestions do more damage than none, because one broken build ends trust for a while. See how to judge autofix suggestions.
Safeguard offers autonomous remediation with fix pull requests. It is off by default and every category starts on Manual, so teams decide what, if anything, is automated. See the fix available now demo and the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what the fix shows before you accept it.
Quick check
Should fixes be applied automatically?
Only where your team has chosen that, with tests and review in place. Start with manual approval for everything.
What if the suggested fix breaks tests?
Treat that as information. Reject or adjust the change, and report the case so the suggestion logic can improve.
Last reviewed: 19 October 2026.
