Only continuous integration should write to a Gradle remote build cache. Developers and CI agents read from it. Gradle's docs expect developers not to populate the remote cache, and the remote push setting is off by default. Keep certificate checks on, because cache entries are build output your machines will reuse.
What a build cache is
Gradle can store task outputs and reuse them when the same task runs again with the same inputs. A remote build cache shares that across machines. The speedup is real. So is the trust: a cached result is executed or packaged as if you had built it locally.
The recommended write pattern
The docs state the expectation that developers will not be allowed to populate the remote build cache, and that CI builds populate it after running the clean task. They also note the local cache push defaults to enabled, while the remote cache push defaults to disabled. The documented pattern sets push only when a CI environment variable exists:
val isCiServer = System.getenv().containsKey("CI")
buildCache {
remote<HttpBuildCache> {
url = uri("https://example.com:8123/cache/")
isPush = isCiServer
}
}
Why write access matters
A wrong entry in a shared cache can be handed to many builds. The docs do not discuss poisoning, so treat this as our own reasoning: whoever can write to the cache can influence what others reuse. The docs do say that missing task inputs can cause incorrect cache hits, where different results share one cache key, which is an accuracy problem you can cause yourself.
Controls
| Control | Why |
|---|---|
| Push only from CI | Limits who can write |
| Restrict CI jobs that may push | Do not let pull request builds from forks write |
| Keep HTTPS certificate validation on | The docs say disabling it lets any cache server impersonate the intended one |
| Do not use allowUntrustedServer | The docs describe it as a temporary measure for tightly controlled networks |
| Authenticate the cache server | Reads and writes should be tied to identity |
| Treat release builds separately | Build releases with a clean, trusted state |
Steps to review your setup
- Find the buildCache block in settings and read the push value.
- Confirm CI is the only writer and that untrusted pull requests cannot push.
- Search for allowUntrustedServer.
- Check cache server access logs for unexpected writers.
- For release artifacts, consider building without the remote cache and comparing.
This is the same question as in build system compromise questions to ask your software vendors, applied to your own pipeline.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice where the gate sits in the flow. Cache push rules belong in the same pipeline conversation.
Safeguard's policies and gates can enforce rules on pull requests before they merge, and the free scan at gold.safeguard.sh/scan covers repository dependencies.
Quick check
Is remote cache push on by default?
No. According to the Gradle docs, the remote cache push defaults to disabled, while the local cache push defaults to enabled.
Is it fine to turn off certificate checks for a private cache?
The docs say it allows any cache server to impersonate the intended one and should be temporary or limited to tightly controlled networks.
Sources
Last reviewed: 19 October 2026.
