Yes. Init scripts run before your settings and project scripts and can configure repositories for every build they attach to. They load from the command line, the Gradle user home and the Gradle install, so a repository can appear in a build that shows nothing in its own files. Know which init scripts your machines and CI images carry.
What they are
Gradle's docs describe init scripts as scripts that run during the initialization phase. They suit shared setup such as enterprise repositories, build listeners and environment specific configuration. The docs also say they affect every build they are attached to and should be managed with the same care as production code.
Where they load from
Per the docs, in order:
| Location | Detail |
|---|---|
| Command line | The I or init-script flag, repeatable |
| Gradle user home | An init.gradle file, plus any init scripts in the init.d directory |
| Gradle install | Init scripts in its init.d directory |
All discovered scripts run, and scripts in one directory run alphabetically.
Why this is a security topic
Because the repository list is part of what shapes a build, an init script that adds one changes where code comes from without touching the project. The docs give this exact use: adding a repository to every project. That is helpful on a corporate CI image pointing at an approved mirror. It is a problem if an unknown script on a developer laptop adds something else.
Init scripts can also register build listeners and read user specific data such as credentials through providers, so they can see sensitive values.
A reproducibility trap
Two people can build the same commit and resolve from different places because their user homes differ. If a bug or advisory only shows on one machine, check init scripts early. The clue appears in the repository lines of a build with debug logging, or by listing the init.d directory.
Steps to audit
- On a CI image and on one developer machine, list the init.gradle file and the init.d directory under the Gradle user home.
- Read every script for repository, plugin and listener changes.
- Check CI job definitions for the init-script flag.
- Prefer repository settings in version control, such as the settings file, where reviewers can see them.
- Version and review the CI image that carries init scripts.
- Add a build check that fails if an unexpected repository host resolves anything.
For settings level control, see how to control where Gradle downloads Android dependencies from.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how monitoring reports change over time. Resolution differences between machines show up as inventory drift.
Safeguard's SBOM and dependency scanning give you a consistent inventory to compare against, and the free scan is at gold.safeguard.sh/scan.
Quick check
Do init scripts live in my repository?
Not necessarily. They can come from the command line, the Gradle user home or the Gradle install, which is why they are easy to miss.
Should I ban init scripts?
Not automatically. They are useful for shared setup. Review them and keep them in controlled images.
Sources
Last reviewed: 19 October 2026.
