Because they often hold the authority to move code, access secrets, or trigger deployments without the same scrutiny applied to human users. If an attacker captures those credentials, the resulting access looks like normal automation. That makes inventory, ownership, and least-privilege scoping central to reducing blast radius.
Why delegated identities and runners become supply chain chokepoints
Delegated identities and CI/CD runners sit in the trust path between code, infrastructure, and release actions. They are often allowed to fetch dependencies, sign artifacts, read secrets, publish packages, or trigger deployments, so compromise of the runner or its identity can turn a narrow foothold into broad supply chain reach. That is why build trust depends on both execution isolation and strong identity scoping, as shown in SLSA.
These identities are high value because they automate legitimate work at machine speed. If an attacker can reuse a token, abuse a workflow, or hijack an ephemeral runner, the activity may blend into normal release traffic. The risk is not just secret theft, it is that the automation itself becomes the delivery mechanism for tampered code, poisoned artifacts, or unauthorized deployment changes, a pattern illustrated by reviewdog Action compromise 2025.
What makes the blast radius so large
The blast radius grows because delegated identities are often connected to multiple systems and environments. A single runner credential may reach source control, package registries, cloud APIs, signing services, or production deployment endpoints, especially when permissions are inherited instead of explicitly bounded. In practice, the most dangerous design is not “automation exists”, it is “automation can touch too much and can do so without strong provenance or short-lived authorization”.
CI/CD pipelines also create a misleading signal for defenders. Actions performed by automation frequently look expected, so adversaries who steal or impersonate a runner identity can hide behind normal workflow execution, scheduled jobs, or pipeline retries. That makes inventory and ownership essential: you cannot scope what you have not enumerated, and you cannot defend a runner whose privileges are unclear or shared across unrelated build jobs.
Least privilege matters here because pipeline credentials are often more powerful than the person who triggered the build. When a bot or runner can read production secrets, push releases, or sign packages, compromise of that identity becomes a supply chain issue rather than a local account issue. A concise example is the exposure pattern seen in ArtiPACKED 2024, where runtime and token exposure turned build data into downstream abuse potential.
How to reduce delegated identity risk without breaking delivery
The control objective is not to remove automation, but to make every delegated identity narrow, attributable, and easy to revoke. Short-lived credentials, explicit trust boundaries, and pinned build inputs reduce the chance that a runner can be reused outside its intended job. Where possible, prefer identity federation and workload-bound authorization over long-lived tokens that survive beyond the build that needed them, a principle reinforced in the OWASP Non-Human Identity Top 10.
Runners should also be treated as managed assets, not disposable conveniences. That means tracking which workflows can invoke them, which repositories or environments they can access, what secrets they can see, and what artifact or deploy actions they can perform. If a runner identity is reused across projects, the compromise of one pipeline can become a cross-repository or cross-environment event, which is why pipeline identity guidance needs to be paired with strict environment isolation and secret segmentation.
Risk and Threat Considerations
Delegated identities and CI/CD runners are attractive to attackers because they concentrate privilege in places that are designed for speed and repetition. A stolen token, poisoned workflow, or compromised self-hosted runner can be used to exfiltrate secrets, alter build outputs, or trigger deployment actions while appearing operationally normal.
Failure mechanism: The attacker abuses a machine-held identity with broad pipeline permissions, then rides trusted automation paths to move from source access to secret access, artifact tampering, or deployment abuse.
Impact: The result can be repository compromise, signing or publishing abuse, secret exposure, and downstream trust failure in consumers who assume the build system is authoritative.
Framework Alignment
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 addresses the attack and risk surface, while SLSA and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and artifact integrity are central to runner and delegated-identity risk. |
| Recommendation — Adopt verifiable build provenance and constrain who can produce release artifacts. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Pipeline identities and runners become dangerous when they hold broader permissions than needed. |
| NHI-07 — Long-Lived Secrets | CI/CD runners are often compromised through reusable tokens that outlive the job. | |
| NHI-09 — NHI Reuse | Reused runner identities and shared automation credentials expand blast radius across systems. | |
| Recommendation — Reduce runner permissions to the minimum required for each workflow. Replace durable pipeline secrets with short-lived credentials and rotate exposed tokens quickly. Avoid sharing automation identities across projects or environments. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Runner credentials and delegated tokens need lifecycle control, rotation, and revocation. |
| AC-6 — Least Privilege | The risk stems from automation granted more access than its task requires. | |
| AU-2 — Event Logging | Automation abuse is hard to distinguish without logs of runner actions and identity use. | |
| Recommendation — Manage pipeline authenticators with expiry, rotation, and revocation discipline. Limit each runner and delegated identity to the smallest required set of permissions. Log runner actions and credential use with enough detail to attribute release activity. | ||
Practitioner Guidance
What to prioritise: Inventory every delegated identity, runner, and pipeline credential that can reach secrets, registries, or production deployment paths. If you cannot name the owner, the scope, and the revocation path, treat it as an open blast-radius problem rather than a tooling detail.
What to verify: Confirm that each runner has a unique purpose, a bounded trust boundary, and credentials that expire quickly enough to be useless after the job completes. Also verify that secret access is job-scoped, not environment-wide by default, and that workflow permissions are narrower than human maintainer access.
Common mistake: Teams secure the repository and still leave the runner overpowered. That leaves the attacker one step away from turning ordinary build execution into a release or secrets channel.
Practitioner takeaway: The decisive control is not whether automation exists, it is whether the automation identity can be compromised without immediately expanding into code, secrets, or deployment authority.
Related resources from NHI Mgmt Group
- How should security teams govern software supply chain risk when CI/CD identities can publish code?
- Why do GitHub Actions workflows create supply chain risk for CI/CD credentials?
- Why do standing CI/CD tokens create so much risk in supply chain attacks?
- Why do exposed software supply chain packages create such a high-risk path to cloud and CI/CD compromise?