Scanners disagree on versions like 1.0.0-rc.1 or 1.0.0+build5 because SemVer gives them special ordering rules. A pre-release ranks below its normal version, and build metadata is ignored when comparing. A tool that compares strings or ignores these rules can flag or miss a version the other tool gets right.
The two rules that matter
The Semantic Versioning specification says pre-release versions have lower precedence than the associated normal version. It also says build metadata must be ignored when determining version precedence, so two versions that differ only in build metadata have the same precedence.
The specification gives an example order.
1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
Notice beta.2 sorts before beta.11, because numeric identifiers compare as numbers. A tool comparing plain strings would put beta.11 before beta.2. It also says numeric identifiers always have lower precedence than non numeric ones.
How this changes a scan
Take an advisory that says versions below 2.0.0 are affected, with the fix in 2.0.0.
| Your version | Correct SemVer result | What a naive tool might do |
|---|---|---|
| 2.0.0-rc.1 | Below 2.0.0, so inside the affected range | Treat it as at or above 2.0 and stay quiet |
| 2.0.0+build7 | Same precedence as 2.0.0, so fixed | Treat the suffix as a newer or older version |
| 1.9.9 | Affected | Affected |
| 2.0.0-beta.11 vs beta.2 | beta.2 is lower | Wrong order in string comparison |
So a release candidate of the fixed version is, by the rules, still before the fix. Whether that matters in practice depends on whether the fix was already in that candidate, which the maintainers' notes will say.
Not every ecosystem uses SemVer
The OSV schema separates range types. SEMVER ranges follow strict SemVer 2.0 ordering. ECOSYSTEM ranges use version strings interpreted by the ecosystem's own rules, which is why the schema recommends an explicit list of versions for them. Python, for example, has its own version ordering. If a tool applies SemVer to a non SemVer ecosystem, edge cases will go wrong.
How to check your own case
- Find the odd version. Look for versions with a dash suffix or a plus suffix in your lockfile.
- Read the advisory range type. SemVer, ecosystem or git.
- Order the versions by hand using the rules above.
- Compare with each tool's verdict. The tool that matches your hand ordering is applying the right rule for that case.
- Report the discrepancy to the tool's maintainers with the example, and record your decision in the meantime.
Practical advice
Avoid shipping pre-release dependencies to production where you can. If you must, pin the exact version and note it in your decision record, because scanners are most likely to disagree there. Prefer a stable release once the fix lands in one.
Treat build metadata as a label. It never makes a version newer or older for matching purposes, and a tool that acts as if it does is comparing the wrong thing.
Quick check
Is 1.0.0-rc.1 newer than 1.0.0?
No. A pre-release has lower precedence than its normal version, so 1.0.0-rc.1 comes before 1.0.0.
Does a plus suffix make a version newer?
No. Build metadata is ignored when determining precedence.
Sources
Last reviewed: 19 October 2026.
