Maven picks the version of the nearest definition: the one closest to your project in the dependency tree. If two versions sit at the same depth, the first declaration wins. That rule can quietly select an older, vulnerable version, so declare the version you want explicitly when it matters.
The rule in the official docs
The Apache Maven introduction to the dependency mechanism describes dependency mediation as the way Maven decides which version of an artifact to use when it meets several. It picks the nearest definition and notes you can always guarantee a version by declaring it explicitly in your project's POM. The docs give an example: with paths A to B to C to D 2.0 and A to E to D 1.0, Maven uses D 1.0 for A, because the path through E is shorter. To force D 2.0, you add it as a direct dependency of A.
Why this is a security issue
Imagine D 1.0 has a published vulnerability and D 2.0 fixes it. Your project never asked for D at all. A transitive path decides, and the shorter path brings the older version. A scan will flag D 1.0, and you may have no direct line in your POM to change.
Fixing it in three moves
- Find the path. Print the dependency tree and locate where the vulnerable artifact enters. The tree shows which parent pulls it in.
- Pin it deliberately. Add the fixed version to your dependency management section, or as a direct dependency, so mediation no longer decides for you.
- Re-test and re-scan. A forced version can break a parent that expected the older API. Run tests, then scan again.
The docs also list dependency management and bill of materials imports as mechanisms for controlling versions across modules, which suits multi-module projects where many teams share one set of versions.
What a new developer should check
- Is there a parent POM or BOM that already manages versions? Look before adding your own.
- Are versions declared in one place or scattered?
- When you add a dependency, read the tree diff, not just your one-line change.
- When a scanner reports a transitive artifact, ask who manages that version.
Comparing approaches
| Approach | Strength | Watch out for |
|---|---|---|
| Rely on mediation | Zero effort | Version chosen by tree shape, not by you |
| Declare directly | Clear and local | Can drift from other modules |
| Dependency management or BOM | One place for the team | Needs an owner to keep it current |
For related guidance, see fixing vulnerabilities in Maven projects.
Where Safeguard fits
Safeguard can do the inventory and watching for you. Its SBOM and dependency scanning lists what a repository actually pulls in, reachability analysis helps separate reachable findings from noise, and policies can gate a pull request. You can try a free scan on a repository to see the output.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how transitive findings are sorted by whether the code path is reachable.
Quick check
Does the newest version always win in Maven?
No. The nearest definition wins, regardless of which version number is higher.
Does Maven have a lockfile?
Not by default. The docs point to declaring versions explicitly as the way to guarantee one.
Sources
Last reviewed: 19 October 2026.
