Under Semantic Versioning 2.0.0, no. Build metadata after a plus sign must be ignored when comparing versions, so 1.0.0+001 and 1.0.0+002 have the same precedence. The catch is that ecosystems differ in how they honour that rule, which is why a scanner can disagree with your package manager.
What the spec says
The SemVer 2.0.0 text is clear. Build metadata may be added after a plus sign, using dot separated identifiers of ASCII letters, digits and hyphens. It must be ignored when determining precedence, so two versions that differ only in build metadata have the same precedence. Precedence compares major, minor and patch numerically, then pre-release identifiers, and build metadata never figures in.
An example: 1.0.0-beta+exp.sha.5114f85 is a beta of 1.0.0 and sorts before 1.0.0. The text after the plus sign changes nothing about that ordering.
How ecosystems treat it
| Ecosystem | Treatment of a plus sign, per its own docs |
|---|---|
| SemVer 2.0.0 | Ignored for precedence |
| NuGet 3.4 and later | Build metadata is removed when matching, so 1.0.7+r3456 is treated as 1.0.7 |
| Maven | Does not special case the plus sign or consider build identifiers |
| Go | Accepts versions with build metadata and converts them to pseudo versions to keep a total ordering |
The Maven documentation says its algorithm is compatible with SemVer 1.0.0 in most cases but not with SemVer 2.0.0. The Go reference says build metadata is ignored for comparison and that the go command converts such versions to pseudo versions. The NuGet docs say normalisation affects how NuGet matches versions when resolving dependencies.
Why this matters for vulnerability matching
Advisory data usually describes affected ranges with an introduced version and a fixed version. A scanner must decide whether your version falls inside. If your version is 2.3.1+patched and the scanner strips the suffix, it compares 2.3.1. If it keeps the suffix as a string, it might sort oddly or fail to parse.
Neither outcome is wrong by itself. The risk is in assuming that a plus suffix signals a fix. Build metadata is a label, often a build number or commit. It does not tell you a vulnerability was patched, and the spec gives it no meaning for compatibility. A vendor build tagged with a suffix needs a vendor statement or a fixed version in the advisory before you treat it as safe.
Steps when you see a plus sign
- Identify the ecosystem, since the rules above differ.
- Strip the metadata and compare the base version to the advisory range.
- Check whether the suffix is documented by the publisher as a patch marker. If it is not, assume it is not.
- If the scanner reports a surprising result, compare how it parsed the version with how your package manager did.
- Record the exact string, suffix included, in your SBOM so the question can be answered later.
What to take away
Treat the part before the plus sign as the identity for comparison, treat the part after as a label, and do not read safety into it. When two tools disagree, the cause is often how each parsed the suffix, and checking the ecosystem's own rules settles it.
Safeguard's SBOM and dependency scanning keeps the version strings your projects resolve to. You can try the free scan on a repository and read the versions it reports.
Quick check
Is 1.0.0+build5 newer than 1.0.0+build4?
Under SemVer 2.0.0 they have the same precedence. Neither is newer, because build metadata is ignored.
Does a plus suffix mean the vulnerability is fixed?
No. It is a label with no defined meaning for fixes. Look for a fixed version in the advisory or a statement from the publisher.
Sources
- Semantic Versioning 2.0.0
- NuGet, Package versioning
- Apache Maven, POM reference, version order
- Go Modules Reference
Last reviewed: 19 October 2026.
