Yes. NuGet 3.4 and later treats 1.0.0.0 and 1.0.0 as the same version. It also removes leading zeros and strips SemVer 2.0.0 build metadata when matching. A scanner comparing NuGet versions as raw strings can therefore disagree with what the package manager restored.
The normalization rules
The NuGet package versioning documentation lists how versions are treated from NuGet 3.4 onward:
| Written as | Treated as |
|---|---|
| 1.00 | 1.0 |
| 1.01.1 | 1.1.1 |
| 1.00.0.1 | 1.0.0.1 |
| 1.0.0.0 | 1.0.0 |
| 1.0.01.0 | 1.0.1 |
| 1.0.7+r3456 | 1.0.7 |
The docs add that pack and restore operations normalise versions whenever possible, and that normalisation does not change the version numbers inside already built packages. It changes only how NuGet matches versions when resolving dependencies. Package repositories must treat these values the same way to prevent duplicate versions of a package, so a repository holding 1.0 of a package should not also host 1.0.0.
Why string comparison goes wrong
Imagine an advisory that lists a fixed version of 2.1.0. Your project file requests 2.1.0.0. A tool that compares strings sees two different values and may report your project as affected, or fail to find any match at all. Under NuGet's own rules they are equal.
The opposite error is also possible. A tool that strips the fourth part might treat 1.0.0.1 as 1.0.0 if it truncates carelessly. The documented rule drops only a zero fourth part, so 1.0.0.1 stays distinct from 1.0.0.
Four part versions are common in the .NET world because older assemblies used the four part form. That makes this more than a corner case for teams with long lived code.
Steps to check your tool
- Find a package in your projects with a four part version, or create a test with one.
- Look at how your scanner and SBOM list it.
- Compare with the version NuGet recorded after restore.
- If they differ in form (1.0.0 versus 1.0.0.0), check that matching against advisory ranges still works.
- Add one test case with a leading zero and one with a plus suffix.
What to put in the SBOM
Record the version as NuGet resolved it, in normalised form, and keep enough information to trace it back to the project file. If you must keep the original string for audit reasons, store both, but make sure the matching key is the normalised one.
This matters when someone asks a simple question such as whether you ship a particular fixed release. If your inventory says 2.1.0.0 and the advisory says 2.1.0, a person can see the match immediately, but a script may not.
Pre-release versions
The same documentation covers pre-release suffixes, such as 6.2.0-beta1, and the version ranges you can write when consuming a package. Pre-release versions sort before the release they lead up to under SemVer. If your project allows pre-releases, make sure the scan reports them with the full suffix.
Safeguard's SBOM and dependency scanning keeps the exact versions your projects resolve to. A free scan on a repository will show what appears in the inventory.
Quick check
Does NuGet treat 1.0.0.1 as 1.0.0?
No. Only a zero in the fourth part is omitted, so 1.0.0.1 stays a distinct version.
Does normalization change the version inside a published package?
No. The docs say it affects only how NuGet matches versions when resolving dependencies.
Sources
Last reviewed: 19 October 2026.
