Pick the smallest upgrade that contains every fix you need and passes your tests. Two scanners can suggest different versions because one reports the first fixed release and the other reports the newest safe release, or because they cover different advisories on the same package. Read the advisories, then choose.
Why the suggestions differ
A fix version is a data field, and the data can be derived in more than one way.
- First fixed version. The OSV schema says the fixed event marks the version that contains the fix. A tool that reports this gives you the minimum.
- Latest release. Some tools simply suggest the newest version, which clears every known issue but may carry larger changes.
- Multiple advisories. A package can have several advisories, each with its own fixed version. A tool that covers all of them must suggest a version that clears the highest fixed value. A tool that sees only one will suggest a lower one.
- Different release lines. A project may maintain two lines, for example 2.x and 3.x, with a fix in each. One tool may point to the line you are on, the other to the newest line.
A decision procedure
- List every advisory on the package for your current version. Use both tools and the project's own notices. Union them.
- Find the fixed version for each advisory on your release line. If an advisory has a fix on your line, you may not need a major upgrade.
- Take the highest of those fixed versions. That is the minimum upgrade that clears all known issues on your line.
- Check the change level. Under SemVer, a patch or minor bump should be backward compatible, but read the release notes. A major bump needs planning.
- Test. Run your test suite and a smoke test on the upgraded build.
- Rescan with both tools. If either still flags the package, read why before you move on.
| Situation | Choice |
|---|---|
| Fix exists on your current line | Upgrade within the line |
| Fix only on a newer major | Plan the major upgrade, or document an accepted risk with an expiry |
| No fix at all | Consider replacing the package, or mitigate and record |
| Two tools differ by one patch | Take the higher, run tests |
Transitive dependencies complicate it
If the vulnerable package is not one you declare, you may have to raise a parent or add an override. In Maven, the dependency mechanism guide says the nearest definition wins and that you can force a version by declaring it directly or through dependency management. In npm the equivalent is an override. Whatever the mechanism, verify in the resolved tree that the new version is the one that actually installs.
Record the choice
Write down the two suggestions, the one you picked, and the reason. If an auditor or customer asks why you did not follow a tool's recommendation, the note answers it.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fix is tied to a specific target version, then compare that with what each of your tools suggests.
Quick check
Is the latest version always the safest choice?
It clears known issues, but it may bring breaking changes and new bugs. Prefer the smallest version that contains all needed fixes, then test.
What if neither tool shows a fixed version?
Check the project's own advisory. If no fix exists, mitigate or replace the package, and record the decision with a review date.
Sources
Last reviewed: 19 October 2026.
