Run mvn versions:display-dependency-updates to list dependencies that have newer versions available. Do not upgrade everything at once. Sort the list by security relevance first, then by size of the version jump, and move in small batches your tests can cover.
Definition
The Versions Maven Plugin from MojoHaus has a goal called display-dependency-updates. It reports dependencies with newer versions available, including dependencies in dependencyManagement and, by default, those used by plugins.
Run it
mvn versions:display-dependency-updates
mvn versions:display-dependency-updates -DallowMajorUpdates=false
Useful parameters from the plugin page:
| Parameter | Default | Effect |
|---|---|---|
| allowMajorUpdates | true | Set false to hide major version jumps |
| allowMinorUpdates | true | Set false to hide minor and larger jumps |
| allowIncrementalUpdates | true | Set false to hide patch level updates |
| allowSnapshots | false | Include snapshot versions |
| ignoredVersions | none | Skip matching versions, such as release candidates |
| showNewestPerSegment | false | List newest incremental, minor and major versions, since 2.23.0 |
The page says that switching off a higher level segment also limits the lower ones, so test your combination.
Is the newest version the safest?
Not automatically. Newer usually means more fixes, but it can mean breaking changes, and a brand new release is also the version an attacker would target if a project were hijacked. A common approach is to prefer the lowest version that includes the fix you need, then move further on your schedule.
Adding it to a routine
Run the report on a schedule, for example weekly in CI, and save the output. A growing list is a signal. A short list that stays short means your upgrades are keeping pace. Pair it with a rule that critical advisories skip the schedule and are handled the same day.
Sorting the list
- Cross-check the list against known advisories. Anything with a known vulnerability goes first.
- Group by update size. Patch updates are cheapest.
- Look at frameworks separately. A framework BOM may manage dozens of versions, see Maven BOMs.
- Skip release candidates and snapshots with ignoredVersions.
- Upgrade a few, run the tests, repeat.
Outdated is not the same as vulnerable. A library can be years behind and have no advisory, and a recent one can have a critical flaw. Use this list for hygiene and a scanner for risk.
Try it yourself
Click through it at your own pace, or open it full screen.
Sort by severity and notice how that ordering differs from simply how old a package is.
Where Safeguard fits
Safeguard's dependency scanning ties known vulnerabilities to your components, so you can sort an upgrade backlog by risk. Try the free scan.
Quick check
Does display-dependency-updates change my POM?
No. It only reports. Other goals in the plugin make changes.
Does outdated mean vulnerable?
No. Check advisories separately. Age and vulnerability are different questions.
Sources
Last reviewed: 19 October 2026.
