Maven Central enforces publishing rules, such as signatures, checksums and POM metadata, but it does not vouch for what a library does. Before adding a dependency, confirm the groupId belongs to the real project, read its POM for extra repositories, check its release history, and review what it pulls in transitively.
What does Maven Central actually guarantee?
Sonatype's published requirements say every component needs a groupId, artifactId and version, and the version cannot end in SNAPSHOT. The POM must carry a name, description, URL, license, developer information and SCM details. Each file needs a matching .asc signature, and .md5 and .sha1 checksums are required. Non-pom projects must supply sources and Javadoc jars, and placeholder jars are allowed when real ones are unavailable.
Read that list again as a reviewer. Every item proves the publisher completed a form. A signature shows that someone holding a key signed the file. It does not tell you whether you should trust that key. A placeholder Javadoc jar is acceptable, so an empty one tells you nothing either.
Where do typosquats and lookalikes hide?
Maven coordinates are two names, not one, so lookalikes have more room. Here is a constructed example. Your team wants a JSON helper and finds two results:
com.acme-tools:json-utilscom.acmetools:json-utils
Same artifact name, near-identical group. Only one matches the domain of the project's real website and repository. Check the project's own documentation for the exact groupId and compare it character by character. If the docs and the repository disagree with the coordinate you found, stop.
Why read the POM and not only the jar?
A POM can declare repositories. The Maven 3.8.1 release notes explain why this matters: Maven Central contains POMs that point at custom repositories over plain HTTP, which makes downloads a target for man-in-the-middle attacks. Because uploaded POMs are immutable, the fix had to live in Maven itself. From 3.8.1, external HTTP repositories are blocked by default through a mirror in conf/settings.xml.
The same notes describe repository order. Repositories in your settings.xml come first, then those inherited through the parent chain up to the super POM, which names Maven Central. Repositories from the effective POMs on the dependency path form the third group. So a dependency's POM can only add sources in its own context, but it is still worth knowing which extra sources a candidate introduces.
What should the release history tell you?
Open the version list for the artifact. Look for a long gap followed by a burst of releases, a first release that is already at a high version number, or a new publisher on an old artifact. None of these proves anything alone. Together they are a reason to read the source diff between the last two versions.
Check the SCM URL in the POM, then confirm the tagged source exists there. The SCM URL need not be public under Central's rules, so a missing repository is a question to ask, not proof of harm.
What to do
- Find the groupId in the project's own documentation and compare it exactly with the coordinate you plan to use.
- Open the published POM. Note any repositories, parent POMs and plugins it declares.
- Run a dependency tree and list every transitive library the new dependency adds.
- Read the release history for gaps, version jumps and publisher changes.
- Pin the exact version in your POM and avoid version ranges for anything new.
- Run a vulnerability and license scan on the full tree, and keep the result with the pull request.
- Re-check when you upgrade, since a new version is a new decision.
For step 6, Safeguard can scan a dependency list for known vulnerabilities, license issues and reachability, and the free in-browser scan at gold.safeguard.sh/scan covers up to 100 dependencies. It supports the checks above and does not replace reading the POM.
Quick check
Does a PGP signature on Maven Central mean the library is safe?
No. Central requires a signature file for each artifact, so its presence only shows a key signed it. You still need to decide whether you trust that key and publisher.
Are external HTTP repositories still allowed in Maven?
Since Maven 3.8.1 they are blocked by default through a mirror in conf/settings.xml. You can define your own mirror to override that, but fixing the repository URL or upgrading the dependency is better.
Sources
Last reviewed: 18 October 2026.
