No. A signature on a Maven Central artifact shows that someone who holds a key published it and that the file has not changed since. It says nothing about whether the code is free of vulnerabilities or malicious intent. Provenance and safety are different questions, and you need to answer both.
What Central actually requires
Sonatype's requirements page lists what a publisher must supply for a deployment: sources and javadoc jars, checksum files (md5 and sha1 are required, sha256 and sha512 supported), a GPG or PGP signature file for every deployed file, and POM metadata. The page also says Central does not attempt to evaluate the javadoc or the source code itself, and it allows placeholder jars where real sources or docs are not available.
Namespaces are verified separately. To publish under a groupId, you prove control of a domain or a code hosting account. That is an ownership check.
Myth versus fact
| Myth | Fact |
|---|---|
| Signed means reviewed | Signing shows the holder of a key produced the file. No code review is implied. |
| Namespace verified means trustworthy | It means the publisher controls a domain or hosting account. |
| Checksums prove the library is clean | They prove the file matches what was published. |
| Central checks for malware or flaws in sources | The requirements page says it does not evaluate source code. |
| Sources jar equals what was built | Placeholder sources are allowed, so check how you rely on them. |
What signatures are good for
They are valuable for a specific job. Gradle's documentation separates the two mechanisms well: checksums verify integrity, meaning the contents have not changed, and signatures verify provenance, meaning who published it. Used together they help ensure you get the right library from a trustworthy author.
Gradle also says the technique is meant to protect you from compromised dependencies, not to stop you including vulnerable ones.
In practice, that means signatures help detect tampering in transit, a swapped file in a cache or a repository mix-up. They do not tell you the maintainer's latest release is secure.
How to cover the other half
- Verify what you download. Use Gradle dependency verification, or a repository manager that checks signatures, so tampering fails the build. See how to enable Gradle dependency verification.
- Scan for known vulnerabilities in every direct and transitive library, on every build and again on a schedule.
- Check reachability, so you spend time on flaws in code paths you actually call.
- Review new and rarely maintained dependencies before adding them, looking at the maintainer, release history and what the library needs to do.
- Keep an SBOM per release so you can answer questions fast.
A note on trust in keys
A signature is only as meaningful as your trust in the key. Gradle's documentation points out that a passing signature from a key you have not decided to trust still fails verification until you add that key. Treat key trust as a review decision, not a click-through.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how many findings drop in priority once call paths are considered, which is the work signatures cannot do.
Safeguard covers that second half for Java and Kotlin projects with dependency scanning, reachability analysis and SBOMs. Run a free scan at gold.safeguard.sh/scan.
Quick check
If a jar fails signature verification, is it definitely malicious?
Not necessarily. Gradle notes signatures are sometimes wrong in the first place, especially across repositories. But treat it as a possible compromise until you confirm against the project's official signatures.
Do unsigned artifacts exist on Central?
Central's requirements call for signatures on all deployed files. Verify that your own tooling actually checks them, since checking is a separate step.
Sources
- Requirements, Sonatype Central documentation
- Register a Namespace, Sonatype Central documentation
- Verifying Dependencies, Gradle documentation
Last reviewed: 19 October 2026.
