Because they are delegated non-human identities with real publishing power. If a bot token can sign, publish, or approve release activity, it needs ownership, scope, rotation, and offboarding controls just like any other privileged credential. Otherwise, a single compromised workflow can become a broad supply-chain compromise.
Why release bots and tokens are not just build plumbing
GitHub Actions release tokens and bot accounts are delegated publishers, not passive automation. If they can sign artifacts, push releases, approve workflows, or trigger downstream deployment, they hold effective authority over what enters the software supply chain. That makes their ownership, scope, rotation, and offboarding part of identity governance, not a separate DevOps concern.
That is why release automation should be treated as a privileged identity surface. A bot token with broad repository or org reach can do more than complete one job, it can make release decisions that downstream systems trust.
What changes when the credential can publish
The governance requirement becomes stricter once a token can affect external trust. A release credential is often tied to package publishing, artifact signing, tag creation, or environment promotion, so compromise can change what customers or internal systems accept as genuine. In that state, secret handling alone is not enough, because the identity itself needs a clear owner, bounded scope, and a defined lifespan.
GitHub Actions is often where those credentials are created, stored, or exchanged, but the real question is whether the identity can be traced back to a responsible team and revoked quickly. That is the same logic applied to other privileged non-human identities: if it can act independently, it needs lifecycle controls that match the blast radius of its authority.
Why release identities fail in practice
Release bots usually fail in predictable ways: long-lived secrets remain valid after the workflow changes, a token is reused across repositories, or a bot is granted extra permissions to make CI friction disappear. The result is a credential that is both operationally convenient and hard to contain once exposed. For GitHub Actions specifically, published artifacts and release steps can become a trusted path for supply-chain compromise, as shown in NHIMG’s tj-actions/changed-files compromise 2025 and reviewdog Action compromise 2025 coverage.
The security issue is not limited to theft. A bot account that is never reviewed, rotated, or retired can silently accumulate access, especially when it is tied to shared service credentials rather than a named owner. Over time, that creates orphaned release authority with no obvious business steward.
Risk and Threat Considerations
Release tokens and bot accounts are attractive because they sit on a trusted execution path and can be used to alter artifacts, tags, or publishing actions at scale. If an attacker obtains that credential, they may not need to break production directly, they can abuse the release process itself to distribute malicious or tampered software through a channel that downstream users already trust.
Failure mechanism: Long-lived or over-scoped release credentials remain valid after compromise, workflow changes, or staff turnover, which lets a stolen token keep publishing or approving until someone notices the downstream impact.
Impact: The compromise can extend beyond one repository, since a release bot often has authority that affects artifact integrity, package distribution, signing trust, and the organisation’s supply-chain reputation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Release bots need revocation when workflows or owners change. |
| NHI-05 — Overprivileged NHI | Publishing tokens often carry more scope than the release step requires. | |
| NHI-07 — Long-Lived Secrets | Release tokens that persist after use increase compromise exposure. | |
| Recommendation — Offboard release bots promptly when their publishing role ends. Reduce release-token scope to the minimum publishing permissions. Rotate release tokens on a short lifecycle and replace durable secrets. | ||
| CIS Controls v8 | CIS-5 — Account Management | Release bots are privileged accounts that need ownership and lifecycle control. |
| Recommendation — Inventory release bot accounts and remove unused publishing access. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Bot tokens are authentication material used to prove release authority. |
| Recommendation — Harden bot authentication so stolen release tokens are hard to replay. | ||
Practitioner Guidance
What to prioritise: Treat every release bot as a named privileged identity with an owner, a purpose, and an expiry condition. The first control question is whether the account or token can still publish, approve, or sign after the workflow no longer needs it.
What to verify: Confirm that release credentials are scoped to the minimum repository, environment, and action set needed for the release path. Verify rotation triggers, revocation procedures, and who is accountable when a release token must be disabled urgently.
Common mistake: Teams often secure the pipeline but leave the publishing credential broad and durable. If the credential can independently change release state, it should be reviewed like any other privileged identity, not treated as a temporary implementation detail.
Practitioner takeaway: The real control objective is not just preventing secret leakage, it is ensuring that any identity capable of publishing software has bounded authority, a clear owner, and a rapid offboarding path.