They can be. A version range lets the resolved version change between builds, a SNAPSHOT is built to move, and Maven's default checksum policy only warns on a bad checksum. None of these is a flaw on its own, but each makes a build less repeatable and harder to audit.
Version ranges
Maven's POM reference defines soft and hard requirements. A plain 1.0 is a soft requirement that other versions in the tree can replace. A bracketed [1.0] is a hard requirement for exactly that version. A range such as [1.5,) means any version from 1.5 up, and Maven picks the highest version that satisfies all hard requirements.
The risk is that the highest matching version changes when a new release appears. Your build today and your build next week can resolve different libraries, with no commit in between. That also means a hijacked or malicious new release can arrive without a review.
The reference also warns about a trap: because 2.0-rc1 sorts below 2.0, the range [1.0,2.0) includes 2.0-rc1 while excluding 2.0, which most people do not expect.
SNAPSHOT versions
SNAPSHOT is how Maven names a version under development. The POM reference says that for version ordering, snapshots are not treated differently from other qualifiers, and that a snapshot sorts below the matching release. Repository policies can enable or disable snapshot downloads separately. Treat a SNAPSHOT dependency in a release build as a defect, since it can change underneath you.
Checksum and update policy
On a repository, checksumPolicy can be ignore, fail or warn, and the default is warn. A warning scrolls past in CI logs. Setting fail makes a bad checksum stop the build.
UpdatePolicy controls how often Maven checks for updates: always, daily by default, interval:X minutes, or never. The reference cautions about never, because metadata changes over time even for release repositories.
What to do
| Concern | Setting |
|---|---|
| Ranges in dependencies | Replace with exact versions, then manage with dependencyManagement |
| SNAPSHOT in releases | Block with an Enforcer rule, see Enforcer rules |
| Bad checksums | Set checksumPolicy to fail on repositories you configure |
| Surprise updates | Keep updatePolicy reasoned, and use a repository manager |
Banning snapshots can be done with bannedDependencies using a version pattern, but test the pattern on a sample build first.
Steps
- Search your POMs for brackets and parentheses in version elements.
- Search for SNAPSHOT in dependency versions.
- Review each repository block for checksumPolicy.
- Replace ranges with exact versions, and record the reason for any that remain.
- Add a CI check.
For the Gradle equivalent, read Gradle dependency locking.
Quick check
What is Maven's default checksum policy?
Warn. Set it to fail if you want a bad checksum to stop the build.
Does a hard requirement like [1.0] make a build repeatable?
It pins that dependency to exactly 1.0, which is repeatable for that artifact. Transitive artifacts still need checking.
Sources
Last reviewed: 19 October 2026.
