Security

GitHub Actions permissions

Ordinary standalone and same-run distributed workflows need only the permissions required by their other steps. The examples use contents: read for actions/checkout; cache restore/save and same-run delta artifact upload/list/download/delete use GitHub-provided, job-scoped Actions runtime credentials rather than the workflow’s GITHUB_TOKEN. Do not grant actions: write for those operations—it is broader than this action needs.

Explicit cross-run or cross-repository artifact lookup is a separate API boundary and is not used by the current ordinary workflow contract. Such a feature requires a token with access to the target run/repository and must document its actions permission at that point. Likewise, grant additional permissions only when another workflow step or an authenticated GitHub API request requires them.

Read-only workers upload no envelopes. Read-only aggregators do not contact the artifact backend at all: their dependent-delta result is skipped-read-only. When possible, skip the aggregator job on pull-request events to avoid allocating a runner that can only perform this no-op.

The github-token input (or GITHUB_TOKEN environment variable) is used only by the Gradle action for authenticated wrapper JAR downloads against the GitHub API. The Maven action does not use it. It is never written to job summaries or persisted in post-action state.

Security

Gradle wrapper verification

Every gradle-wrapper.jar provisioned by this action goes through a three-step verification chain before it is written to disk:

1. SHA-256 checksum — the expected digest is downloaded from services.gradle.org over HTTPS and compared to the downloaded JAR bytes.
2. Detached OpenPGP signature — the ASCII-armored .asc signature is downloaded from services.gradle.org and verified against a pinned Gradle signing-key allowlist using a fresh ephemeral GnuPG home. The pinned keys live in src/build-tool/gradle/wrapper/signature.ts.
3. Race-condition guard — the JAR is written atomically via a temporary file so a partially written JAR is never exposed to the Gradle invocation.

The key allowlist is designed to support smooth Gradle signing-key rotation: old and new keys may overlap in the allowlist. Remove a retired key only after it no longer signs any wrapper version you intend to support.

To override the GnuPG binary (for example, on Windows runners where multiple gpg variants may exist), set the BUILDISH_MAMMOTH_CACHE_GRADLE_GPG_COMMAND environment variable before the action runs.

Token scoping

• github-token is used exclusively by the Gradle action for authenticated requests to api.github.com and raw.githubusercontent.com when downloading wrapper JARs. It is applied per-host so it is never sent to any other endpoint.
• The token is never written to workflow summaries, log output, or post-action state.

Threat model

Assumed attacker capabilities

The threat model considers two attacker categories:

• External attacker — no repository access, no ability to push commits or create pull requests. An external attacker cannot interact with the repository’s GitHub Actions cache at all.
• Contributor with pull-request access — can open a pull request and trigger pull_request / pull_request_target workflow runs. This is the primary threat actor for cache-poisoning scenarios.

Actors with direct push access to a repository’s default branch are considered trusted. The security posture of CI in general degrades when untrusted actors gain push access, which is outside the scope of this threat model.

Impact of a successful cache poisoning

GitHub Actions cache entries are scoped to a branch and a workflow. A poisoned cache entry means that malicious files — for example, a trojaned build-tool JAR or a plugin that executes arbitrary code — can be injected into a future build that restores from that entry. Because the build tool (Gradle or Maven) loads and executes JARs from its local cache directory, arbitrary code execution within the build is a realistic impact of a successfully poisoned entry.

The most dangerous scenario is poisoning the default branch (main / master) cache, because all PR builds fall back to it via the restore key chain.

Mitigations already in place

Residual risks

• Cache entries are not verified against their generation digest at restore time. GitHub’s cache backend selects entries by key prefix and creation time. A malicious actor with cache-write access can publish a newer generation in a compatible lineage, and the action does not rehash the restored archive before use. This is a fundamental limitation of the underlying @actions/cache service.
• Third-party plugin JARs are not re-verified after the initial build. Once a plugin JAR is cached, subsequent restores trust the cache entry. A poisoned entry that replaces a legitimate plugin JAR will execute on the next build without further verification. Mitigate this by using lockfiles, dependency verification (Gradle’s --write-verification-metadata), or read-only: true on jobs where cache freshness is not required.
• main branch cache affects all subsequent workflows. A single poisoned save to the default-branch cache lineage propagates to every future build on that branch until a clean generation becomes the newest entry. Treat cache write access with the same sensitivity as push access.

Hard cache safety exclusions

The following paths are excluded from every active partition unconditionally and cannot be overridden.

Gradle

Maven