An automatic fix pull request reads the fixed version from a vulnerability advisory, changes your manifest or lockfile to that version, runs your existing tests in a branch, and opens a pull request for a person to review. Merging stays under your rules. The tool proposes; your policy decides.
The five steps behind the pull request
- Match. The scanner finds a component and version in your dependency inventory that falls inside an advisory's affected range.
- Find the fix. Advisories in the OSV format record where a range ends with a fixed event, which "precisely identifies the version which contains the fix." If only a last affected version is given, there is no confirmed fix version to move to.
- Choose a target. The tool picks the smallest upgrade that clears the range. Semantic versioning helps here: a patch bump is meant to hold only backward compatible bug fixes, a minor bump adds compatible features, and a major bump may break callers.
- Edit and test. It changes the manifest or lockfile in a branch and runs your CI. Green tests are evidence, not proof.
- Open the pull request. The description should say which CVE, which versions, and what changed.
Which fixes are safe to automate?
| Change type | Typical risk | Sensible default |
|---|---|---|
| Lockfile only, patch version | Low | Review, then merge on green CI |
| Manifest change, minor version | Medium | Review by code owner |
| Major version | High, API may change | Manual, with migration notes |
| No fixed version exists | Not a bump at all | Mitigation or ticket, not a PR |
The semver promise is only a promise. Maintainers sometimes break it, so tests and a human read still matter for anything touching production paths.
What to check before merging
- The pull request touches only dependency files unless you expect more.
- CI ran against the branch, and covers the code that uses the package.
- The new version is the fixed version in the advisory, not just the latest.
- No new transitive packages you do not recognise appeared in the lockfile diff.
Try it yourself
Open the demo and follow a finding from advisory to proposed upgrade. Look at how the fix version is chosen and what the diff contains.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard's autonomous remediation opens fix pull requests. It is off by default and every category starts on Manual, so nothing merges until you choose. Policies and gates control what is allowed. A free scan shows which of your findings have a fixed version today.
Quick check
Does a fix pull request replace code review?
No. It replaces the manual lookup and edit. Someone still needs to read the diff and confirm tests cover the affected code.
What if the advisory has no fixed version?
Then there is nothing to upgrade to. Use a mitigation, replace the package, or track an exception with an owner and a date.
Sources
- OSV schema, ossf.github.io/osv-schema (introduced, fixed and last_affected events).
- Semantic Versioning 2.0.0, semver.org (meaning of major, minor and patch).
Last reviewed: 19 October 2026.
