Yes. Gradle dependency verification compares each downloaded artifact with checksums or signatures you recorded, no matter which repository or mirror served it. That makes it a useful second check on a mirror. Its weak point is bootstrapping, because the first file it generates trusts whatever your repositories hold on that day.
What verification does
Gradle's documentation describes dependency verification as meant to protect you from compromised dependencies. You enable it by committing a verification-metadata.xml file under the gradle directory. The file stores expected checksums and optionally trusted signing keys for each artifact. It applies to the root project, subprojects and buildSrc.
On a mismatch, the default strict mode fails the build early, before the suspect code is used. A missing entry also fails the build. Lenient mode prints errors without failing, and off ignores verification.
Checksums and signatures differ
| Check | Proves | Does not prove |
|---|---|---|
| Checksum | The file has not changed since you recorded it | Who published it |
| Signature | Who signed the artifact | That the signing key is trustworthy to you |
The docs state it plainly: checksums alone verify integrity but not authenticity. For the strongest protection they recommend both, and they note that MD5 and SHA-1 are insecure, so prefer SHA-256 or SHA-512.
Why this pairs well with a mirror
A mirror can serve a poisoned file if its cache is tampered with or if it cached something malicious from upstream. Verification does not care about the path. If the checksum differs from the one you recorded earlier, the build stops. So the mirror gives you availability and control, and verification gives you an independent integrity check.
The bootstrapping caveat
You create the metadata with a Gradle command that writes checksums, or checksums plus signatures. The docs warn that this trusts whatever is currently in your repositories, so you must review the generated file. Entries marked as generated by Gradle need checking, and you should change them to verified once confirmed. A dry run option writes a preview file without overwriting yours.
If you bootstrap while your mirror is already holding a bad artifact, you have just blessed it. So bootstrap from a point you trust, and review the diff of the metadata file in every pull request that changes it.
A routine for a small team
- Bootstrap with checksums and signatures where artifacts offer them.
- Review entries marked as generated, and confirm a sample against the upstream publisher.
- Commit the file and require review for any change to it.
- Keep strict mode on in CI.
- When a dependency update adds new entries, ask whether the version and publisher look expected.
Where Safeguard fits
Safeguard's pull request policies and gates can run alongside verification, flagging dependency changes in a pull request so a reviewer sees them. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a pull request is held until a dependency change is reviewed, which is the habit a metadata file needs.
Quick check
Does verification replace a mirror?
No. It checks integrity of what you download. A mirror gives control over what is available.
Is a checksum match proof the package is safe?
No. It shows the file matches what you recorded, not that the recorded file was benign.
Sources
Last reviewed: 19 October 2026.
