No. Gradle dependency verification checks that each downloaded artifact matches a checksum or signature you recorded, so a tampered file fails the build. It does not know whether a legitimate version has a known vulnerability. You need both: verification for integrity, and a scan for known advisories.
What verification does
The Gradle user guide explains two methods. With checksums, the build tool keeps a list of expected hashes for each artifact. You record the expected checksum, such as a SHA-256 value, in the gradle/verification-metadata.xml file. When the build downloads that artifact, Gradle computes the checksum of the downloaded bytes, and if it does not match the expected value, the build fails instead of using the file. Signatures are the second method, where a cryptographic signature is checked against trusted keys.
By default Gradle verifies both artifacts, such as JARs and ZIPs, and their metadata files, such as POM files, Ivy descriptors and Gradle Module Metadata.
The guide also states the scope. The configuration is global: a single file verifies the entire build, covering all subprojects, the root project and buildSrc. With an included build, the current build's file is used and any verification metadata in the included build is ignored.
What it does not do
A checksum answers one question: is this the same file I recorded? If you recorded the checksum of a version that was already vulnerable, verification will pass every time. It is a guard against substitution, such as a compromised mirror serving a different file, not against using a flawed release.
| Question | Verification metadata | Vulnerability scan |
|---|---|---|
| Was this file altered after I approved it? | Yes | No |
| Does this version have a known advisory? | No | Yes |
| Did a dependency appear that I have not reviewed? | Strict mode flags artifacts missing from the file | Only if the scan covers the change |
How to use them together
- Generate a baseline. The guide says the most efficient way to begin is by generating metadata for your existing build, because the configuration is global and strict.
- Scan the dependency set at the same time and fix what matters before you freeze checksums for the versions in use.
- When you update a dependency, regenerate the metadata for the change, review the diff, and run the scan again.
- Treat a verification failure as a signal to investigate, not to bypass. The guide describes ways to disable verification for specific configurations, which should stay rare and documented.
The pull request that changes verification-metadata.xml deserves a real review. A reviewer should ask who requested the new dependency and why, since a checksum entry for a new artifact approves it.
The review habit
When the metadata file changes in a diff, look for three things: a new group or module that was not there before, a checksum that changed for an existing version number (which should never happen with a properly released artifact), and any loosening of verification settings.
Where scanning fits
A scan tells you what to update, and verification keeps you honest about what you actually downloaded. Neither replaces the other. If you have only one today, add the other.
Safeguard's SBOM and dependency scanning covers the advisory side of this pairing, and the free scan lets you try it on a repository.
Quick check
Does a passing verification mean my dependencies are safe?
No. It means the files match what you recorded. A recorded version can still have known vulnerabilities.
Is the verification file per subproject?
No. The guide says it is global, one file for the whole build including subprojects.
Sources
Last reviewed: 19 October 2026.
