Running any binary on your computer is inherently risky and gradlew is no exception, especially since it directly affects products that you ship to your customers. I wanted to share a couple of tips to improve the sitation.

• Do not hastily run ./gradlew on an external project you checked out.
  • Replace their Gradle wrapper with a one you trust.
  • Squint at buildSrc/ and *.gradle files before running.
  • Run in a VM if possible
• Validate Gradle wrapper JAR checksum every time you upgrade and using GitHub Action if you use GitHub.
• Set distributionSha256Sum=XXX in gradle-wrapper.properties to validate that gradle-X.X-bin.zip actually matches SHA256 provided by Gradle.
• Use a trustworthy and up-to-date JDK to run Gradle (e.g. Amazon Corretto or Zulu)
• Carefully pick your Gradle plugins, annotation processors, Kotlin and Java compiler plugins. Each one brings in risk, especially if it is a closed source artifact.
• Enable Gradle dependency signature verification to make sure that artifacts you use (especially on build classpath) are signed with a trusted key (example configuration file from AndroidX). It will help catch man-in-the-middle attacks and any incidental artifact modifications. It is a fairly painful feature to set up (a couple of Gradle bugs), but the gains are high.
  • Complain to projects that do not sign or only partially sign their artifacts (throwing a rock into my own AndroidX garden), for example Kotlin Gradle Plugin and Android Gradle Plugin
  • Sign your libraries, if you ship any.
• Never publish locally built artifacts, ideally it all comes from a reproducible clean Virtual Machine build.

This will not solve all of your problems, but it will get you in a better shape.