Should I Use JitPack or Maven Central for Android Libraries? A Security and Reliability Guide

Feb 22, 2026

Cowrie

Dev @ Bswen

Problem

I found a critical supply chain vulnerability in my Android project’s build.gradle:

build.gradle

repositories {
    maven { url 'https://jitpack.io' }  // SECURITY RISK
}

dependencies {
    implementation 'com.github.example:library:1.0.0'  // Mutable artifact!
}

The issue: JitPack artifacts can change even with “pinned” version numbers. If the source repository gets compromised, attackers can rebuild the artifact on JitPack’s servers, and your build will fetch the malicious version—all while you think you’re using a safe, versioned dependency.

This isn’t theoretical. Android developers have reported multiple instances where JitPack builds failed or produced different artifacts for the same version tag. The platform rebuilds from source on cache miss, so even version tags don’t guarantee immutability.

Why This Matters

Supply chain attacks are the #1 security threat in modern software development. When you depend on mutable artifacts:

• You can’t guarantee what code runs in production
• You can’t reproduce builds consistently
• You can’t verify artifact authenticity
• You expose your app to repository takeover attacks

For Android apps handling user data or payments, this is unacceptable.

JitPack vs Maven Central

Here’s the core comparison:

Aspect	JitPack	Maven Central
Artifact Immutability	❌ Mutable (rebuilds from source)	✅ Immutable (cannot change after publish)
GPG Signing	❌ No artifact signing	✅ Mandatory GPG signatures
Build Control	❌ Built on JitPack’s servers	✅ Built and signed by author
Reproducibility	❌ Builds can differ	✅ Reproducible builds guaranteed
Cache Behavior	❌ Rebuilds on cache miss	✅ Artifacts never change
Repository Security	⚠️ Depends on GitHub/GitLab security	✅ Sonatype’s hardened infrastructure
Setup Effort	✅ Easy (just push a tag)	⚠️ Requires GPG key setup and Sonatype account

The critical difference: Maven Central artifacts are cryptographically signed and immutable. Once published, version 1.0.0 will always be the exact same bytes. JitPack artifacts are built on-demand from source code, so version 1.0.0 today might be different from version 1.0.0 tomorrow if the source repository changes.

How JitPack’s Architecture Creates Risk

JitPack’s workflow looks like this:

Your build requests library:1.0.0
         ↓
    JitPack checks cache
         ↓
    Cache miss? → Clone GitHub repo
         ↓
    Build from source on JitPack servers
         ↓
    Return artifact (unsigned)

The problem steps:

1. Source repository compromise: If an attacker gains access to the GitHub repository, they can modify the source code
2. JitPack cache invalidation: JitPack rebuilds on cache miss or explicit cache clearing
3. Your build fetches malicious version: Your Gradle build downloads the newly-built, compromised artifact
4. No signature verification: Since JitPack builds aren’t signed, you can’t detect tampering

Even worse, you might not even notice. The version number stays 1.0.0, but the artifact content changes completely.

Maven Central’s Security Model

Maven Central’s workflow is fundamentally different:

Author builds artifact locally
         ↓
    Author signs with GPG key
         ↓
    Upload to Maven Central
         ↓
    Sonatype verifies signature
         ↓
    Publishes immutable artifact

The security steps:

1. Build on author’s machine: The author controls the build environment
2. GPG signing: Every artifact is cryptographically signed
3. Signature verification: Maven Central validates signatures before publishing
4. Immutability guarantee: Once published, artifacts cannot be modified or overwritten

When you depend on a Maven Central artifact, you’re not just trusting the author—you’re verifying that the artifact bytes haven’t changed since publication.

Migration Example

I migrated a project from JitPack to Maven Central. Here’s what changed:

Before (JitPack):

build.gradle

repositories {
    maven { url 'https://jitpack.io' }
}

dependencies {
    // Using GitHub shorthand
    implementation 'com.github.user:repo:1.0.0'
}

After (Maven Central):

build.gradle

repositories {
    mavenCentral()
}

dependencies {
    // Standard Maven coordinates
    implementation 'io.example:library:1.0.0'
}

The library author needs to publish to Maven Central instead of just pushing a GitHub tag. But from the consumer’s perspective, it’s actually simpler—no custom repository URL needed.

How to Check if Libraries Are Available

Many libraries are published to both repositories. Check availability:

# Check Maven Central for library
curl -I https://repo1.maven.org/maven2/io/example/library/1.0.0/library-1.0.0.pom

# If HTTP 200, it exists on Maven Central
# If HTTP 404, it's not available there

Most popular Android libraries have Maven Central versions. If you’re using a library that’s JitPack-only, consider:

• Requesting the author add Maven Central publishing
• Forking and publishing yourself (with permission)
• Finding an alternative library with proper distribution

Build Reliability Differences

Beyond security, I found JitPack has reliability issues:

• Build failures: JitPack sometimes loses builds or fails to build from source
• Cache inconsistencies: Different regions might serve different artifacts
• Downtime: JitPack has experienced outages affecting builds worldwide
• Rate limiting: High-traffic projects might hit JitPack’s rate limits

Maven Central, operated by Sonatype, has enterprise-grade infrastructure with:

• 99.9% uptime SLA
• Global CDN distribution
• No build process (artifacts are pre-built)
• No rate limiting for public repositories

Common Mistakes

I’ve seen developers make these mistakes:

1. Assuming pinned versions are immutable: Version pinning only works if the repository guarantees immutability
2. Not checking repository source: Gradle allows maven { url '...' } anywhere—audit your build files
3. Ignoring GPG signature warnings: Gradle doesn’t warn about missing signatures by default
4. Using JitPack for convenience: Easy setup doesn’t justify security risks

The Migration Decision

When I audit my dependencies, I use this decision tree:

Is the library available on Maven Central?
    YES → Use Maven Central
    NO →
        Is this a production app with user data?
            YES → Find an alternative library
            NO →
                Can I contact the author to publish to Maven Central?
                    YES → Request migration
                    NO → Use JitPack with caution, document the risk

For production apps, there’s rarely a good reason to accept JitPack’s security model.

The Reason

The key issue is that JitPack’s architecture prioritizes convenience over security. By rebuilding artifacts from source code on-demand, JitPack creates a fundamental security vulnerability: the artifact you download might not match the artifact you reviewed yesterday.

Maven Central’s design prioritizes security and reproducibility. Artifacts are signed by the author, verified by the repository, and guaranteed to never change. This aligns with supply chain security best practices and modern compliance requirements.

The Android community has recognized this risk. Many library authors who previously used JitPack have migrated to Maven Central. When I switched my libraries to Maven Central publishing, build reliability improved and security concerns vanished.

Summary

In this post, I compared JitPack vs Maven Central for Android library distribution. I explained why Maven Central’s immutable artifacts and mandatory GPG signatures make it the only secure choice for production apps. The key point is that JitPack’s rebuild-from-source architecture creates supply chain vulnerabilities that version pinning cannot mitigate—migrate to Maven Central for any serious Android development.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

• 👨‍💻 Reddit discussion on JitPack supply chain risks
• 👨‍💻 Maven Central publishing guide
• 👨‍💻 Reproducible Builds verification
• 👨‍💻 OWASP Supply Chain Security

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags:

• mobile
• security
• java

How to Use Gradle verification-metadata.xml for Dependency Security

How to Secure JitPack Dependencies in build.gradle Against Supply Chain Attacks