Gradle dependency verification compares the checksums and signatures of the libraries and plugins your build downloads against values you approved and committed in gradle/verification-metadata.xml. It catches a modified artifact, not a malicious one that was approved. A human still has to decide what to trust.
What it protects against
Android's documentation describes the risk directly: a malicious actor could inject a modified dependency during resolution, for example through a man in the middle attack. It adds that a compromised library can change how your app runs on a device, and a compromised plugin can change how your build works or even run commands on the build machine. Verification is a control for exactly that gap between what you meant to download and what arrived.
Checksums versus signatures
| Method | Strength | Upkeep |
|---|---|---|
| Checksums | Simple, works for any artifact | Change with every release, so you update the file on each upgrade |
| Signatures | Tied to the author's key, survive version upgrades | More work for library authors, and you must trust the key |
Android's guide notes that if an author signs each version with the same key, you do not need to update the metadata file when you upgrade. That is attractive for SDKs from vendors that sign consistently.
How to enable it
- Create gradle/verification-metadata.xml with verification of metadata and signatures turned on.
- Bootstrap trusted keys and checksums:
./gradlew --write-verification-metadata pgp,sha256 --export-keys help
- Open the generated files and review them. Android's guide warns that whenever you bootstrap or update checksums and signatures, you should verify that you trust them. Bootstrapping records what you downloaded today. It does not prove today's download was good.
- Commit the metadata file and the keyring.
- For Android Studio sync, trust source and javadoc artifacts as the guide shows.
If verification fails, Gradle reports a failure and writes an HTML report you can open for details.
Where it fits in SDK governance
Verification answers one question: is this the artifact we approved? It does not answer whether the SDK should have been approved. Use it after the approval step in your workflow, and with a lockfile that fixes versions.
A failing verification after a routine upgrade needs a short, defined response:
- Check whether the SDK vendor rotated a signing key and announced it.
- Compare the new artifact with the previous one if you can.
- If you cannot explain the change, do not update the trusted entry. Hold the upgrade and ask the vendor.
Never solve a failure by deleting the verification file. That turns off the control exactly when it fired.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings change over time for an unchanged component. Verification proves the artifact is the one you approved. Monitoring tells you when an approved artifact later gets an advisory.
Safeguard's dependency scanning and policies cover that second half. A free scan is at gold.safeguard.sh/scan.
Quick check
Does verification stop a malicious but approved SDK?
No. It confirms the bytes match what you approved. Review decides whether to approve.
Should the metadata file be committed?
Yes. Android's guide says it is checked into version control.
Sources
Last reviewed: 19 October 2026.
