Add a dependency constraint for the fixed version. A Gradle constraint sets a version requirement for a module without adding it as a dependency, and it takes part in conflict resolution when something pulls that module in. By default a constraint means at least this version, so make it strict if you need an exact one.
Why plain declarations fall short
Gradle's documentation says version declarations, including ranges, only affect the dependencies you declare directly. To control the versions of transitive dependencies, use dependency constraints. So adding a dependency line for a library you do not call just to force a version is the older workaround, and constraints are the cleaner one.
The basic constraint
dependencies {
implementation("com.example:app-library:3.2.0")
constraints {
implementation("com.google.guava:guava:33.0.0-jre")
}
}
If app-library pulls in guava at an older version, the constraint lifts it. If guava is not pulled in at all, nothing is added. That second behavior is why constraints keep your dependency list honest.
At least, or exactly
The documentation says constraints are not strict by default and usually express a minimum, so Gradle can still select a higher version. You can make them strict, or use rich versions with ranges, prefer, reject or strictly when you need tighter control.
| Need | Use |
|---|---|
| Never below the patched version | A plain constraint |
| Exactly this version | A strictly constraint |
| Block one known bad version | A reject on the constraint |
A minimum is usually the right security choice. It lets future patch releases flow in while ruling out the vulnerable range.
Constraints travel
The documentation notes that constraints are transitive. If library A depends on B, and B declares a constraint on C, that constraint affects the version of C that A resolves. That is useful when you publish your own libraries, and it is a reason to review constraints in libraries you consume.
One limit: dependency constraints are only published when using Gradle Module Metadata. Consumers using Maven or Ivy may not see them. If you publish a library, remember that your downstream users on other tools may not receive your security constraint.
Step by step
- Identify the vulnerable module and the fixed version from your scan.
- Find the path that pulls it in with the dependencyInsight task.
- Add a constraint in the build file, or in a shared platform so every project picks it up. See Gradle platform or Maven BOM.
- Rebuild and run the insight task again to confirm the selected version.
- Add a comment with the advisory reference so the constraint can be removed once the upstream library catches up.
Check that it stuck
The most common mistake is trusting the build file instead of the resolution result. Always confirm from the resolved graph. An SBOM generated after the build records what Gradle selected, which is useful evidence. The Gradle fix guide covers the wider workflow.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the fixed version is surfaced next to the finding, which is the number you put in the constraint.
Safeguard dependency scanning identifies the fixed version, and autonomous remediation can open a fix pull request. It is off by default and every category starts on Manual. Free scan: gold.safeguard.sh/scan.
Quick check
Does a constraint add the library to my project?
No. It only applies when something else brings the module in.
Will Maven users of my library see my constraint?
Not necessarily. Constraints are published through Gradle Module Metadata, so consumers on other tools may not receive them.
Sources
- Dependency Constraints, Gradle documentation
- Viewing and debugging dependencies, Gradle documentation
Last reviewed: 19 October 2026.
