Because the identity can act outside the specific build step that needed access. A broad service account role lets a future pipeline run, or an attacker who controls it, reach buckets, secrets, and infrastructure without a fresh governance decision.
Why standing permissions in GitLab pipelines are risky
Standing permissions turn a pipeline identity into a reusable access path, not a one-time build privilege. In practice, that means the credential or role can be abused outside the narrow job that justified it, so a later run, a poisoned dependency, or a compromised runner can reach systems that should have required a fresh approval decision.
GitLab pipelines often touch code, artifacts, registries, cloud services, and deployment targets in a single workflow. If the same permission set persists across runs, the blast radius grows from one build step to the whole automation boundary, and the control failure is usually privilege that outlives the task.
That is why guidance for CI/CD security increasingly favors short-lived, task-scoped access over reusable credentials, especially where the pipeline can read secrets or write to production infrastructure. The safer pattern is to make access expire with the work, not survive it.
How standing permissions expand the blast radius
Standing permissions are dangerous because pipelines are repeatable and often indirectly reachable. A token or role that was intended for one repository, one branch, or one deployment can be reused by another job, another maintainer, or an attacker who gains control of the pipeline context. NHIMG’s CI/CD Pipeline Identity Security Guide is a useful reference for the controls that reduce that exposure.
The risk grows when the pipeline can access storage buckets, signing keys, package registries, or cloud management APIs. Once those privileges are always on, compromise is no longer limited to build output integrity, because the pipeline identity itself becomes a standing route into the environment. That is the same pattern behind broad privilege and credential persistence problems across CI/CD systems. Just-in-Time Access and Zero Standing Privilege Guide explains why time-bound access is the safer default.
Standing access also weakens governance. If nobody has to re-approve access for each meaningful action, the organisation loses a clean decision point for who is allowed to deploy, rotate secrets, or reach production resources. That makes audit trails less useful and exception handling much harder to justify.
Why GitLab pipeline permissions become an attacker’s shortcut
Attackers like standing permissions because they compress the path from initial foothold to high-value assets. If a pipeline secret, runner credential, or deployment role stays valid after the original job ends, the attacker does not need to race a short expiry window or re-open a fresh approval path. A GitLab token that reaches cloud APIs, artifact stores, or secret managers can become a pivot into much larger compromise.
GitLab pipelines are especially attractive when they are trusted to pull code, fetch dependencies, and publish artifacts automatically. That trust means a single secret leak or job hijack can translate into lateral movement across build, test, and release systems. The practical lesson from real-world CI/CD incidents is that persistence in the pipeline often matters more than the first point of entry. CI/CD pipeline exploitation case study shows how pipeline access can be turned into host compromise, and 17,000+ Secrets Exposed in Public GitLab Repositories shows how easily GitLab-hosted secrets can be exposed at scale.
Once a standing permission can authenticate to another service, the attacker’s goal shifts from breaking in to reusing trust. That is why overprivileged automation should be treated as a direct exposure problem, not only as a pipeline hygiene issue.
Risk and Threat Considerations
Standing permissions create both exposure and persistence risk. If the pipeline identity can still act after the job that needed it has finished, any later compromise of the runner, repo, or secret store can convert into access to buckets, registries, cloud control planes, or deployment systems.
Failure mechanism: The same long-lived permission is reused across runs, so compromise of one pipeline path becomes reusable access to unrelated systems. An attacker only needs to capture or reuse the standing credential once to bypass the original approval boundary.
Impact: The blast radius expands from a single build step to the wider delivery and infrastructure estate. That can mean secret theft, unauthorized deployment, data exposure, or privilege escalation into production services.
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 NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Standing pipeline permissions are overprivileged machine access that expands blast radius. |
| NHI-07 — Long-Lived Secrets | Reusable pipeline credentials create lasting access beyond the build step. | |
| Recommendation — Right-size pipeline access and remove any permissions the job does not actively need. Replace long-lived pipeline secrets with short-lived, job-scoped credentials. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Pipeline credentials need lifecycle controls for issuance, rotation, and expiration. |
| AC-6 — Least Privilege | The issue is excessive access rights granted to automation beyond the needed task. | |
| IA-9 — Service Identification and Authentication | Pipeline-to-service access is machine authentication, not human user access. | |
| Recommendation — Enforce secret rotation, expiry, and revocation for pipeline authenticators. Limit pipeline roles to the minimum permissions required for each job. Use strong machine-to-machine authentication for pipeline identities and bound their scope. | ||
| NIST Zero Trust (SP 800-207) | AC-6 — Least Privilege | Zero trust requires minimizing standing access and verifying each access path. |
| Recommendation — Verify each pipeline action and deny any persistent access that is not needed. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Standing pipeline tokens that reach APIs can be reused after the intended job ends. |
| Recommendation — Bind pipeline API access to short-lived credentials and revoke unused tokens promptly. | ||
Practitioner Guidance
What to prioritise: Treat any pipeline credential that can outlive the job as a risk asset, then inventory where it can write, read secrets, or assume higher roles. If it can reach production infrastructure, it should be the first candidate for replacement with short-lived access.
What to verify: Confirm whether the permission is bound to a branch, job, environment, or artifact, and whether it expires automatically after use. If the answer is no, assume the access path is broader than the team intended.
Decision rule: If a pipeline needs the credential only during a specific step, prefer ephemeral federation or JIT-style access over a reusable token. If a standing permission must remain, document the exception, narrow the scope, and require explicit owner review for every high-impact action.
Practitioner takeaway: The core question is not whether the pipeline is trusted, but whether the trust is still valid when the job ends. If access remains reusable, the pipeline has become an identity with standing privilege, and that is where the security risk starts.
