What breaks when GitHub admin and publish permissions are left standing in CI/CD environments?

Why This Matters for Security Teams

Standing GitHub admin and publish permissions turn a CI/CD runner into an already-authorised attacker surface. Once a token is stolen, the problem is not limited to repository read access. The same identity can push malicious changes, alter workflows, publish compromised packages, and pull secrets from adjacent systems before detection catches up. That is why the CI/CD pipeline exploitation case study matters: pipeline identity is often the fastest path from initial access to supply chain impact.

This is also where private repositories create false confidence. GitGuardian’s State of Secrets Sprawl 2026 found that internal repositories are 6x more likely to contain secrets than public ones, which means standing publish authority can expose more than code. In practice, many security teams encounter the blast radius only after a malicious release or workflow tampering has already occurred, rather than through intentional privilege review.

The issue is amplified because CI/CD identities are machine identities, not human users. The OWASP Non-Human Identity Top 10 treats these credentials as high-risk assets precisely because they are easy to reuse, hard to observe, and often granted more privilege than the workload actually needs.

How It Works in Practice

CI/CD permission failures usually start with convenience. A service account, GitHub App, deploy token, or runner credential is granted admin or publish access so pipelines can operate without manual intervention. That works until the token is copied into logs, leaked from an action, inherited by a forked workflow, or harvested from a compromised runner. At that point, the identity does not merely authenticate, it authorises destructive actions at machine speed.

Current guidance suggests replacing standing access with time-bound elevation and narrow task scope. The practical pattern is: verify the workload identity, issue short-lived credentials only when a job is approved, and revoke them on completion. This is where workload identity primitives such as SPIFFE/SPIRE or OIDC-backed federation become important, because they prove what the workload is rather than assuming the token should remain valid indefinitely. Pair that with policy-as-code and runtime checks, so publish permission is granted only for a release job, only from a trusted branch, only on a signed build, and only for the minimum artifact target.

• Separate build, test, and publish identities instead of reusing one privileged token.
• Use just-in-time elevation for admin actions and remove standing publish rights from default runners.
• Bind secrets to job context with short TTLs and automatic revocation.
• Evaluate authorisation at request time with context, not just with static roles.

That operating model aligns with the Ultimate Guide to NHIs — Key Challenges and Risks, which frames over-privileged machine identities as an avoidable control failure, not an inevitable tooling tradeoff. These controls tend to break down when legacy release workflows require broad repo admin rights across multiple self-hosted runners because the trust boundary becomes too wide to enforce consistently.

Common Variations and Edge Cases

Tighter CI/CD access often increases release friction, requiring organisations to balance deployment speed against blast-radius reduction. That tradeoff is real, especially in large monorepos, multi-tenant runners, or environments where package publishing and repository administration are handled by the same automation path.

There is no universal standard for this yet, but current guidance suggests avoiding one long-lived identity for all pipeline stages. For example, a build job may only need read access plus artifact signing, while a publish job needs narrow write access for a single package or release asset. If the same token can also modify workflow files, the pipeline can self-escalate by changing the next run. That is why GitHub admin permissions are especially dangerous: they can convert a code execution event into persistent control over future automation.

Another edge case is secret sprawl outside the repository. The State of Secrets Sprawl 2025 shows that collaboration tools and project systems also carry critical secrets, so revoking one GitHub token may not stop the breach if downstream systems still trust the same identity. The guidance becomes even less reliable when deploys depend on manual approvals, shared service accounts, or tokens that outlive the job that created them.

In those environments, least privilege is necessary but not sufficient. The practical answer is to combine short-lived credentials, branch and environment protections, and rapid revocation with continuous review of who can publish, approve, or rewrite workflow logic.

Related resources from NHI Mgmt Group

• Why do standing NHI permissions make PassRole abuse more dangerous?
• What breaks when industrial access still depends on standing credentials?
• What breaks when compromised IAM credentials still have standing privilege in AWS?
• What breaks when machine identity sprawl is left unmanaged?