How does versions-maven-plugin help you stay on top of outdated dependencies, and how is it different from a vulnerability scanner?
answer
- org.codehaus.mojo versions plugin
- display-dependency-updates / -plugin-updates
- use-latest-releases rewrites pom
- freshness not security
- complements dependency-check
basics
~10 sversions-maven-plugin reports newer available versions of your dependencies and plugins (for example with display-dependency-updates) and can update your pom. It only checks for newer versions, not for security vulnerabilities.
solid answer
~40 sversions-maven-plugin (groupId org.codehaus.mojo) inspects your declared dependencies and plugins, queries the repositories, and tells you what newer versions exist. Common goals: `display-dependency-updates` (lists deps with newer releases), `display-plugin-updates`, `use-latest-releases`/`use-next-releases` (rewrite the pom), and `update-properties`. It is about freshness and maintenance, not security: it does not know about CVEs. dependency-check answers 'is this version vulnerable?'; versions-maven-plugin answers 'is there a newer version?'. They are complementary — staying current is the cheapest way to avoid many vulnerabilities, but a newer version is not automatically a safe one, and sometimes the safe move is a targeted patch upgrade rather than jumping to the latest. In CI you typically run display-dependency-updates as an informational report rather than auto-bumping.
code
bash · 4 linesmvn versions:display-dependency-updates
mvn versions:display-plugin-updates
# Rewrite pom to next releases (then run tests!)
mvn versions:use-next-releasesgo deeper
Know display-dependency-updates lists newer versions of your dependencies.
Know the main goals and that it is about freshness, distinct from CVE scanning.
Decide between latest vs. targeted patch upgrades and treat updates as reviewed PRs, not blind auto-bumps.
Establish an upgrade strategy combining versions reports, dependency-check gating, and automated PR tooling across repos.
## What it is `versions-maven-plugin` (groupId `org.codehaus.mojo`) is a maintenance tool for keeping your dependency and plugin versions current. It does **not** scan for vulnerabilities — it only knows about version numbers available in your configured repositories. ## Key goals - `versions:display-dependency-updates` — prints which **dependencies** have newer versions available. - `versions:display-plugin-updates` — same for **build plugins**. - `versions:display-property-updates` — for versions managed via `<properties>`. - `versions:use-latest-releases` — rewrites the pom to the latest **release** (non-SNAPSHOT) versions. - `versions:use-next-releases` — bumps to the next release only (smaller jump). - `versions:update-properties` — updates version properties. - `versions:set` — sets the project's own version (handy for releases). ## Example output ```bash mvn versions:display-dependency-updates # ... # org.apache.commons:commons-lang3 .... 3.12.0 -> 3.14.0 # com.fasterxml.jackson.core:jackson-databind 2.15.0 -> 2.17.1 ``` ## How it differs from a vulnerability scanner | Question | Tool | |---|---| | Is there a newer version? | versions-maven-plugin | | Is this version vulnerable (has a CVE)? | dependency-check | They complement each other. Routinely upgrading (versions plugin) is the single cheapest way to *avoid* CVEs, because most fixes ship as new releases. But: - A newer version is **not guaranteed safe** — it can introduce its own CVE. - The latest version can bring breaking changes; sometimes the right fix is a **targeted patch bump** that dependency-check tells you resolves the specific CVE, not a blind jump to latest. ## Practical usage - Run `display-dependency-updates` as an **informational** CI report, not an automatic gate, because new versions can break the build. - Prefer `use-next-releases` or property updates with tests over `use-latest-releases` to control blast radius. - Combine: dependency-check flags a vulnerable lib; versions plugin shows what newer versions exist to upgrade to.
- Does upgrading to the latest version guarantee you are not vulnerable?No. The latest release can carry its own undiscovered or newly disclosed CVE, and may also break your build. Pair upgrades with dependency-check and tests.
- Why run display-dependency-updates as a report instead of auto-bumping in CI?Blindly jumping to latest can introduce breaking changes; you want a human (or tested PR) to review the upgrade rather than fail or silently change the build.
saying these in an interview costs you the question
- Claiming versions-maven-plugin detects vulnerabilities — it only knows versions, not CVEs.
- Assuming use-latest-releases is always safe — it can break builds and is not a security guarantee.