A Maven SNAPSHOT version, such as 1.0-SNAPSHOT, marks a project that is still in development. Because the same version string can point to different builds over time, it is not repeatable. Production builds and anything you must audit should depend on a fixed release version.
What the docs say
Maven's getting started guide says the SNAPSHOT designator in a version indicates a project in a state of development. The release guide describes the release step: if the development pom holds 1.0-SNAPSHOT, the release version would be 1.0, and the next development version is set after that, typically a higher SNAPSHOT.
So a snapshot is a moving target by design. A release is meant to be final. Maven Central makes that explicit for public components: it does not remove or modify components once available, so users can rebuild repeatably.
Snapshot versus release
| Aspect | SNAPSHOT | Release |
|---|---|---|
| Meaning | In development | Final for that version |
| Same version, different bytes? | Yes, by design | No, should never change |
| Safe for audit and rollback? | No | Yes |
| Good for | Local and integration testing | Staging and production |
Why it is a security problem, not only a tidiness one
If a dependency resolves to a snapshot, two builds a day apart can contain different code under one version number. A scanner result for that version may not describe what you ship. An attacker who can publish to a snapshot repository can change what your build pulls without raising a version. And a rollback cannot restore the exact earlier build.
How to keep snapshots out
- Put snapshots in a separate repository from releases, with different write rights.
- In production pipelines, fail the build if any dependency or the project version ends in SNAPSHOT.
- Cut a release for anything that leaves the development environment, using the release process in the Maven guide.
- Promote the released artifact through environments rather than rebuilding it.
- After release, bump the project to the next SNAPSHOT.
If a released version has a bug, do not overwrite it. Maven Central's advice is to publish a new release, ideally a patch release if you use semantic versioning.
See also build once, promote the same artifact.
Safeguard's policy gates can block a pull request or release when a dependency violates a rule you set, and its SBOM scanning records the exact versions resolved in each build.
Quick check
Can I deploy a SNAPSHOT to production?
You can, but you lose repeatability: the same version may contain different code tomorrow. Release a fixed version instead.
How do I fix a bad release on Maven Central?
You cannot replace it. Publish a new release with the fix and tell users to move to it.
Sources
- Maven in 5 minutes, getting started
- Releasing a project, Maven
- Immutability of Published Components, Maven Central
Last reviewed: 19 October 2026.
