Gradle Security Considerations
Posted on 2022-05-13
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
./gradlewon an external project you checked out.
- Replace their Gradle wrapper with a one you trust.
- Squint at
*.gradlefiles 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.
gradle-wrapper.propertiesto validate that
gradle-X.X-bin.zipactually 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.