Gradle dependency verification checks that downloaded artifacts match recorded checksums, and optionally that they carry trusted signatures. It protects you from tampered or substituted files. It does not tell you whether a dependency has a known vulnerability, and Gradle says so itself.
Scope, in Gradle's words
The documentation states that dependency verification is meant to protect yourself from compromised dependencies, not to prevent you from including vulnerable dependencies. Those are two different jobs, and you need a separate tool for the second.
Gradle describes two complementary mechanisms.
| Mechanism | Verifies | Limit |
|---|---|---|
| Checksums | The artifact contents have not changed | Integrity only, not who published it |
| Signatures | Who published the artifact | May rely on weak hashes if the signature does |
The documentation recommends using signatures when available and falling back to checksums when artifacts are unsigned, and says that for the strongest security you use both. It adds that if a signature uses an unsafe hash, even SHA-1, you are not correctly assessing file integrity.
How it works in practice
Verification is driven by a verification metadata file in your project. The documentation covers generating and bootstrapping it, with options for checksums only or checksums and signatures, plus a dry-run mode, and ways to update it automatically or manually. It also covers configuring key servers, keyrings and trusted keys.
A typical adoption path:
- Generate the metadata with checksums for the current build, and commit it.
- Review it once. The first generation trusts what you downloaded at that moment, so this is a trust on first use step. Treat it with care.
- Turn on signature verification where artifacts are signed, and decide which keys you trust.
- Run builds in strict mode so a mismatch fails.
- When you add or upgrade a dependency, update the metadata in the same pull request and review the new entries.
What a failure tells you
The documentation includes troubleshooting for missing metadata, incorrect checksums, untrusted signatures and failed signature verification. A checksum mismatch for a version you already trusted deserves a real investigation, because an artifact that changes under a fixed version is exactly what the control exists to catch. A missing entry, by contrast, usually means someone upgraded without updating the metadata.
How it fits with locking
Locking decides which versions. Verification decides whether the files for those versions are the expected ones. Both can be committed, both change in pull requests, and both are readable diffs. Neither judges security of the code itself.
What to add alongside
Scan the resolved dependencies for known vulnerabilities, and review new direct dependencies before adding them. Verification gives you confidence you installed the thing you meant to install; it cannot tell you the thing was a good idea.
Where Safeguard fits
Safeguard covers the part Gradle leaves out: dependency scanning and SBOM generation for known vulnerabilities, with reachability analysis to show which ones your code can call. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Open the inventory and find where vulnerability data attaches to each package, which is the information verification does not provide.
Click through it at your own pace, or open it full screen.
Quick check
Does Gradle dependency verification detect vulnerable libraries?
No. The documentation says it protects against compromised dependencies, not against including vulnerable ones.
Checksums or signatures?
Use both where you can. Checksums show integrity, signatures show who published, and the documentation recommends combining them for the strongest result.
Sources
Last reviewed: 19 October 2026.
