A scanner usually suggests the lowest version at or beyond the advisory's fixed event that still fits your dependency constraints. It reads the fixed version from the advisory, then checks that nothing else in your tree blocks the upgrade. The suggestion can fail when the fix needs a major version jump or when a parent package pins the old one.
Step 1: read the fixed event
Advisories in the OSV format describe affected versions as ranges made of events. A range has an introduced event and usually a fixed event, and can use last_affected when no fix exists. The first version where the fixed event applies is the earliest release that closes the issue on that line.
If a record has only last_affected, or no fix at all, the scanner has no target to suggest. A trustworthy tool says "no fix available" rather than guessing.
Step 2: consider several release lines
Many projects maintain more than one release line, such as 1.x and 2.x. An advisory can list a fix for each. The right suggestion is the fix on your current line, not the highest number overall. Jumping from 1.4 to 2.0 might close the issue and also break your build.
| Your version | Fixed versions listed | Sensible suggestion |
|---|---|---|
| 1.3.0 | 1.4.3 and 2.1.0 | 1.4.3 (same line) |
| 2.0.5 | 1.4.3 and 2.1.0 | 2.1.0 |
| 0.9.0 | 1.4.3 only | 1.4.3, but expect a major jump |
Step 3: check the dependency tree
For a direct dependency, the upgrade is one edit. For a transitive one, the scanner must find which parent pulls it in and whether the parent allows the fixed version. npm's audit tooling describes this with the idea of a meta-vulnerability: a dependency that is vulnerable because it depends on vulnerable versions of another package. The fix may be upgrading the parent, not the child. See fixing a vulnerable transitive dependency for the manual route.
Step 4: estimate the risk of the change
A patch bump is typically low risk, a minor bump moderate, a major bump high. Better tools mark which kind of change they are suggesting, so a reviewer knows how much testing to expect.
Why a suggestion may be wrong
- The fixed version exists in the advisory but is not yet published to your registry.
- Another constraint in your tree blocks the version.
- The fix is backported by your operating system vendor under a different version number, so the scanner's suggestion is not the way you would fix it.
- The "fix" changes behaviour you rely on.
Always run tests on the change, whether a person or a tool made it.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which version is suggested and what the tool says about the size of the change.
Where Safeguard fits
Safeguard's autonomous remediation can open a fix pull request for a finding. It is off by default, with every category set to Manual, so a person approves each change. Run the free scan to see suggested fixes on your own project.
Quick check
Should I always take the newest version?
No. The smallest change that closes the issue on your release line is usually safest. Larger jumps need more testing.
What if no fixed version is listed?
Look at mitigations, a replacement package, or removing the dependency, and record the decision with an owner and a review date.
Sources
Last reviewed: 19 October 2026.
