Every Gradle build pulls in code from external repositories, executes tools you didn’t author, and publishes artifacts that others will trust. Each step is a potential attack surface.

For a typical Gradle build, the supply chain has three layers:

  1. Repositories: where artifacts are stored and served.

  2. Dependencies: the libraries and plugins your project consumes.

  3. Build Tool: Gradle itself, including the Wrapper, init scripts, and everything under ~/.gradle.

Attacks can originate at any layer and then propagate downstream through published artifacts, transitive dependencies, or compromised tools. Even the build tool itself is an attack vector.

securing builds 1

Gradle provides features to protect each layer:

Layer Common issues and attacks How to protect it

Repositories

  • Dependency-confusion attacks against private coordinates

  • Leaking private package names to public mirrors

  • Artifacts from unauthenticated or plaintext-HTTP repositories

Centralize repository declarations, require HTTPS, restrict which coordinates each repository is allowed to serve, and mark internal artifacts as exclusive to internal repositories.

Dependencies

  • Typosquatting and name-squatting

  • Compromised or replaced artifacts

  • Silent version drift from dynamic versions

  • Publicly disclosed vulnerabilities in code the author intentionally published

Screen for known vulnerabilities, verify artifact checksums to protect integrity, and verify PGP signatures to protect provenance.

Build Tool

  • Tampered Wrapper JAR or distribution

  • Compromised init scripts under ~/.gradle/init.d

  • Compromised buildSrc or included builds

  • Poisoned local or remote caches

  • Credentials leaked through plain-text gradle.properties or the configuration cache

Pin and verify the Gradle Wrapper and distribution, protect the Gradle User Home, guard init scripts and buildSrc, protect caches and the daemon, and stay on a supported Gradle release.