A Gradle supply chain review comes down to ten questions: where code comes from, what versions resolve, whether bytes are verified, and what runs inside the build itself. Work through them in order for any Java, Kotlin or Android project. Each links to a deeper post, and each can be checked in a few minutes.
The ten questions
| # | Question | Where to look |
|---|---|---|
| 1 | Which repositories can the build use, and who approved them? | Settings file, repositories blocks |
| 2 | Can a project add its own repository? | repositoriesMode setting |
| 3 | Are private groups restricted to the private repository? | Content filters |
| 4 | Where do plugins and JDKs come from? | pluginManagement, toolchain settings |
| 5 | Are any versions dynamic or SNAPSHOT? | Build files, catalog, dependency report |
| 6 | Are resolved versions locked? | Lock files |
| 7 | Are artifact checksums verified? | Verification metadata |
| 8 | Who can change build logic? | buildSrc, build-logic, init scripts |
| 9 | Who can write to shared caches? | Build cache settings |
| 10 | Is there an inventory per shipped variant and target? | SBOM, dependency report |
Quick guidance for each
1 and 2. Gradle's docs describe a settings level repositories block, and a mode that fails the build when a project declares its own. Android's default template uses it. See Google Maven and Maven Central.
3. Gradle's content filtering restricts a repository to named groups, and exclusiveContent makes one repository the only source. See keeping private groups off public repos.
4. Plugins resolve from the Plugin Portal unless you configure otherwise, and JDKs are downloaded only if a resolver is configured. See plugin sources and JDK auto-download.
5. Gradle says dynamic versions and changing modules can make builds unreproducible. See SNAPSHOT and changing modules.
6 and 7. Locking fixes versions, verification checks bytes. See turning on locking and bootstrapping verification.
8. Build logic is code, and init scripts affect every build they are attached to. See reviewing convention plugins and init scripts.
9. Gradle's docs expect only CI to populate a remote cache. See who should push.
10. Declarations are not the same as resolved graphs, especially across Android variants and Kotlin Multiplatform source sets.
Scoring it
Mark each question as yes, partly or no, and write the owner and date next to it. Three or more no answers on questions 1 to 7 is a good reason to start with repositories and locking, since those are quick changes. Re-run the list when the team adds a platform target, a new plugin or a new repository.
What to hand a customer
If a buyer asks about your build, a filled in version of this table, with dates and owners, is concrete and honest. Do not claim a certification you do not hold, and say plainly which items are in progress.
Try it yourself
Click through it at your own pace, or open it full screen.
See how findings are tracked from detection to closure. Your checklist answers should be tracked the same way.
Safeguard's SBOM and dependency scanning, policies and gates, and compliance and evidence automation cover parts of this list. The free scan is at gold.safeguard.sh/scan.
Quick check
Which question should I answer first?
Start with repositories, since where code comes from affects everything after it, and the change is small.
How often should I rerun the review?
At least when you add a repository, plugin or target, and on a regular schedule such as each quarter.
Sources
- Gradle: Declaring repositories
- Gradle: Centralizing repository declarations
- Gradle: Repository content filtering
- Gradle: Dependency versions
- Gradle: Build cache
Last reviewed: 19 October 2026.
