What breaks when GitHub Actions workflows use mutable dependencies and overprivileged tokens?

Where the trust boundary actually breaks

Mutable dependencies break the assumption that approval time and execution time are the same. In GitHub Actions, a workflow can be reviewed against one version of an action and then run a different version later if the reference is not pinned. That means the pipeline is no longer executing the reviewed code path, it is executing a moving target.

This is why pinned references, protected release tags, and commit-SHA pinning matter. If the workflow depends on a mutable action, any later tag update, branch rewrite, or compromised upstream release can change behaviour without changing the workflow file itself. For teams that want a deeper practitioner view of this failure mode, the CI/CD Pipeline Identity Security Guide is a useful reference point, because it treats pipeline trust as an execution problem, not just a configuration problem.

The same break appears when overprivileged tokens are available to that workflow. A token with broad repository or org scope can turn a small dependency change into write access, secret reads, release tampering, or lateral movement across the build and delivery path. The issue is not just that a secret exists, but that the secret grants more authority than the workflow truly needs.

Why mutable actions plus broad tokens create compounding exposure

GitHub Actions supply chain failures usually become dangerous when two mistakes line up: the dependency can change after review, and the runtime token can do too much if that change is malicious. A compromised action does not need to “hack” the repository in a traditional sense if the workflow already hands it a token with permission to push commits, open releases, alter packages, or read secrets.

That combination expands the blast radius from a single CI job to repository control. With a broad token, a malicious or modified action can exfiltrate secrets, poison build outputs, tamper with release artifacts, or plant persistence for the next run. This is why hardening the workflow identity and the token scope is part of the same control problem as dependency integrity. The reviewdog Action compromise and the tj-actions/changed-files compromise both show how a poisoned action can convert CI trust into secret exposure at scale.

That is also why workflow identity should be treated as a bounded authority model. A job token should only be able to do the specific work required for that step, and nothing else. When a workflow can publish, approve, or read protected material without a separate trust decision, the pipeline stops being a controlled automation path and becomes an implicit access path.

What good looks like in practice

Good practice is to reduce the workflow to the minimum authority needed for the exact step being executed. Pin third-party actions to immutable commit SHAs, scope tokens per job, separate read-only build steps from release steps, and keep secret access out of jobs that do not need it. Where possible, replace long-lived credentials with short-lived, audience-bound federation so the workflow proves what it is doing at run time instead of carrying broad standing power.

CI/CD pipeline identity security guidance is most valuable when it is used to decide which steps may authenticate, which may publish, and which should never see secrets at all. The practical question is not whether a workflow is “trusted” in the abstract, but whether each token is bounded enough that a dependency swap cannot turn into repository compromise.

For teams managing release automation, this also means reviewing whether the workflow needs write permission, secret access, or package-publishing rights on every trigger. If the answer is no, remove them. If the answer is sometimes, split the workflow so the high-risk authority exists only in the narrow path that truly needs it.

Risk and Threat Considerations

Mutable dependencies and overprivileged tokens create a classic supply-chain abuse pattern, one where compromise is often invisible until secrets leak or a release is altered. The danger is amplified in CI because the attacker does not need a user session, only the ability to influence an action reference or abuse the permissions already granted to the runner.

Failure mechanism: A workflow resolves a different action version than the one reviewed, or a stolen/mis-scoped token gives that action more authority than intended. The malicious code can then read secrets, modify repository state, or weaponise the pipeline for follow-on compromise.

Impact: The organisation loses the guarantee that approval means control. The likely outcomes are secret exposure, poisoned builds, tampered releases, and repository-level persistence that can spread through other projects and automation paths.

Practitioner Guidance

What to verify: Confirm that all external actions are pinned to immutable references and that workflow tokens cannot write, publish, or read secrets unless that step explicitly requires it.

Decision rule: If a workflow can still succeed after its token is stripped down, reduce the permissions now. If it cannot, split the job so only the release-bearing step retains elevated access.

Common mistake: Treating repository approval as sufficient control even though the executed action can change later. In CI, trust has to survive both dependency drift and token misuse.

Practitioner takeaway: The core control objective is to make sure the reviewed workflow is also the one that runs, and that any token it receives is too narrow to turn dependency drift into compromise.

Related resources from NHI Mgmt Group

• What actions should I take if my OAuth tokens are compromised?
• What breaks when GitHub Actions workflows run untrusted pull requests with write access?
• How should security teams govern GitHub Actions workflows that use secrets to update policy stores?
• What breaks when GitHub Actions workflows are reachable from outside the organisation?