Add an exclusion inside the dependency that brings the library in, then declare a fixed version yourself if the code still needs it. Or skip the exclusion and pin a patched version with dependencyManagement. Exclude to remove a library you do not need. Pin to keep one you do.
Definitions
A transitive dependency is one you did not declare but received because a library you declared needs it. An exclusion tells Maven to drop a named artifact from that path. DependencyManagement sets the version Maven uses whenever the artifact appears anywhere in the tree.
Option 1: exclude it
The Maven guide puts it plainly: if project X depends on Y, and Y depends on Z, the owner of X can explicitly exclude Z.
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
<exclusions>
<exclusion>
<groupId>group-c</groupId>
<artifactId>excluded-artifact</artifactId>
</exclusion>
</exclusions>
</dependency>
The exclusion lives inside the dependency that carries the unwanted artifact. If three of your dependencies pull it in, you may need it in all three.
The risk is that the code path using the library still runs. You then get a NoClassDefFoundError at runtime, not at build time. Run the tests that exercise the feature before you ship.
Option 2: pin a fixed version
When you still need the library, set its version once:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
<version>2.0.0</version>
</dependency>
</dependencies>
</dependencyManagement>
The Enforcer documentation notes that this applies to all transitive dependencies with the same groupId, artifactId and classifier. That is why it beats the default rule where the nearest definition wins, covered in Maven dependency mediation.
Decision table
| Situation | Use |
|---|---|
| Library is unused in your code path | Exclusion |
| Library is needed and a fixed version exists | dependencyManagement pin |
| Many modules share the fix | Pin in a parent POM or BOM, see Maven BOMs |
| No fixed version exists | Exclude if possible, otherwise document and monitor |
Steps
- Run
mvn dependency:tree -Dincludes=group:artifactto find every path to the library. - Choose exclusion or pin from the table.
- Rebuild and rerun the tree to confirm the resolved version.
- Add a comment naming the advisory so nobody removes the pin later.
- Rescan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for which findings already have a fixed version listed. Those are the ones a pin can solve today.
Where Safeguard fits
Safeguard's dependency scanning shows which findings have a fix available, and autonomous remediation can open fix pull requests. That feature is off by default and every category starts on Manual. Run a free scan on a repository to see your own transitive paths.
Quick check
Does an exclusion work for every path?
No. It applies only on the dependency where you declare it. Other dependencies that bring in the same library need their own exclusion, or use a pin instead.
Will the build fail if I exclude something I need?
Usually not. The failure tends to appear at runtime when the missing class is loaded, so test the affected feature.
Sources
Last reviewed: 19 October 2026.
