No, not for anything you ship. A changing module keeps the same version string while its contents change, and a Maven SNAPSHOT always points to the latest published artifact. Gradle's docs say dynamic versions and changing modules can lead to unreproducible builds, and recommend dependency locking when you use them.
Definitions
A dynamic version is a range such as 5.+ or a placeholder for the latest version. A changing version is one whose contents can change while the version string stays the same. Maven SNAPSHOT versions are the main example, and any version can be marked as changing by setting the changing flag on the dependency.
| Type | Example | What moves | Reproducible? |
|---|---|---|---|
| Fixed version | 2.1.0 | Nothing | Yes |
| Dynamic version | 2.+ | Which version is picked | No |
| Changing module | 2.1.0-SNAPSHOT | The bytes behind the same string | No |
Why this matters for security
A scan result is tied to a specific set of bytes. If a SNAPSHOT changes after you scanned, the scan no longer describes what you build. A fix can appear, and so can a regression or a malicious change. You also cannot answer later which code shipped in a given release.
Android's guidance says the same about dynamic versions: you should not use them, because they can cause unexpected version updates, difficulty resolving version differences and poor performance.
When SNAPSHOTs are legitimate
Inside your own organization, during active development of two modules together, SNAPSHOTs are convenient. The problem is carrying them into release builds or customer facing artifacts, and pulling in third party SNAPSHOTs from public repositories.
Controls
- Fail release builds on SNAPSHOT or dynamic versions. A simple check on the resolved graph is enough.
- Use locking where dynamic versions remain, as in turning on Gradle dependency locking.
- Verify checksums with dependency verification so a changed artifact fails the build.
- Pin internal modules to release versions before tagging a release.
- Record versions in an SBOM for each release.
For the mobile specific angle, see why avoid dynamic versions in mobile releases.
Steps to find them today
- Search build files and catalogs for SNAPSHOT, plus signs and ranges in brackets.
- Run a dependency report on the release configuration and search the output the same way.
- Replace each with a released version, or document why not.
- Add a CI check so they do not return.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice that each finding is tied to a component and version. A moving version makes that link unreliable.
Safeguard's dependency scanning and policies can flag components by version and gate releases on your rules, and the free scan is at gold.safeguard.sh/scan.
Quick check
Does a SNAPSHOT version change?
Yes. The Gradle docs say a Maven SNAPSHOT module always points to the latest artifact published.
Does locking fix a SNAPSHOT?
The docs recommend locking for reproducibility with dynamic versions. For changing modules, also verify checksums, since the string stays the same.
Sources
Last reviewed: 19 October 2026.
