Run the dependencyInsight task with the dependency name and a configuration. Gradle prints every path that leads to the dependency and a selection reasons section that explains why that version won, such as conflict resolution, a constraint or a forced version. Use it to decide which requirement to change when a scan flags a version.
Definitions
Configuration. A named set of dependencies, such as compileClasspath or runtimeClasspath.
Conflict resolution. The rule Gradle uses to choose one version when several are requested.
Constraint. A rule that influences the selected version without adding a dependency by itself.
Two tasks to know
The dependencies task renders a tree for every configuration of a project, with the selected version and conflict resolution details. In its output, an asterisk marks a repeated subtree shown once in full, and a letter c marks a constraint.
The dependencyInsight task answers a narrower question. It needs a dependency, as a full group and name or a partial match, and a configuration. In Java projects the configuration defaults to compileClasspath. Optional switches show a single path or all variants.
./gradlew -q dependencies --configuration runtimeClasspath
./gradlew -q dependencyInsight --dependency commons-codec --configuration runtimeClasspath
Selection reasons you will see
| Reason in the report | What it means | What you can change |
|---|---|---|
| Was requested | A direct or transitive declaration asked for it | The declaring dependency |
| By conflict resolution | Several versions were asked for, one won | Raise the lowest request, or add a constraint |
| By constraint | A constraint influenced it | The constraint |
| By ancestor | A strict version from a parent enforced it | The parent |
| Selected by rule | A resolution rule overrode the default | The rule |
| Forced | A platform or strategy set it | The platform or strategy |
Steps for a flagged version
- Take the group, name, and vulnerable version from the scan.
- Pick the configuration that ships, usually runtimeClasspath.
- Run dependencyInsight and read all paths.
- Check the selection reason. If it was conflict resolution, a constraint on the fixed version may be enough.
- If a rule or strict version forces it, change that rule.
- Rebuild, rerun the task, and confirm the new version.
- Re-scan.
Tips
- Check each configuration that matters, since test and runtime sets differ.
- Prefer a constraint with a because note, so the next person understands it.
- Do not use a forced version without a comment and a review date.
Try it yourself
Click through it at your own pace, or open it full screen.
Expand the inventory and trace which direct dependency brings in a given package.
Quick check
Why does the same library appear at two versions in my tree?
Different configurations, or different requests that Gradle resolved to one version. The insight report shows the paths and the reason.
Should I force a version to fix a finding?
As a last step. A constraint or a parent upgrade is cleaner and easier to review.
Safeguard SBOM and dependency scanning covers Java builds and ranks findings by whether your code reaches them. Run a free scan on a repository.
Sources
Last reviewed: 19 October 2026.
