CI/CD pipeline access to GitLab needs short-lived tokens

At a glance

What this is: This is a GitLab-focused cookbook on using short-lived OAuth 2.0 tokens for CI/CD pipeline access so teams can replace hardcoded credentials with scoped, identity-based machine access.

Why it matters: It matters because CI/CD pipelines are high-value NHI actors, and IAM teams need lifecycle, revocation, and scope controls that work for ephemeral machine access rather than human-style access patterns.

Context

CI/CD pipeline identity is the access model that lets build and deployment systems call downstream services without human intervention. In GitLab-connected workflows, the governance problem is not just whether the pipeline can authenticate, but whether the credential format, scope, and lifetime match the task being performed.

Hardcoded credentials create a standing access problem because they persist beyond the job that needs them. Short-lived OAuth 2.0 tokens narrow that window, but the real control question is whether the pipeline has identity lifecycle management, revocation discipline, and least-privilege scope that align with machine execution rather than human accounts.

For identity teams, this is a familiar NHI pattern: the access path is only as safe as the assumptions behind issuance, rotation, and offboarding. The article is a practical reminder that CI/CD access to GitLab should be governed as workload identity, not treated as an implementation detail.

Key questions

Q: What breaks when CI/CD pipelines rely on hardcoded GitLab credentials?

A: Hardcoded credentials create standing access that outlives the job that needed it, which makes reuse, leakage, and offboarding failures much more likely. Once a pipeline secret exists in code, config, or build tooling, it becomes difficult to prove where it was copied, who can still use it, and when it should be revoked.

Q: Why do short-lived tokens reduce risk for GitLab API access from pipelines?

A: Short-lived tokens reduce the time window in which a stolen or exposed credential can be reused. They also force teams to tie access to a specific workload and task, which narrows blast radius. The control only works well when scope is minimal and revocation is reliable when the pipeline changes.

Q: What are the signs that pipeline secrets are not under control?

A: Common warning signs include credentials in source code, config files, or CI/CD variables, broad permissions that exceed the job's needs, and tokens that remain valid after a pipeline has been retired or replaced. Those patterns show that access is being managed as a secret stash rather than as a governed identity lifecycle.

Q: Should organisations treat CI/CD pipeline access like human IAM access?

A: No. Pipeline access should follow the same governance discipline as other non-human identities, but the controls need to fit machine execution. That means runtime issuance, narrow scope, and lifecycle ownership instead of passwords, broad standing access, or recertification assumptions built around people.

Technical breakdown

Why hardcoded CI/CD credentials are fragile

Hardcoded credentials turn a pipeline job into a standing bearer of access. Once a token, password, or key is embedded in code, config, or build tooling, the credential can survive the specific run that needed it and remain usable elsewhere. That breaks the normal containment model for CI/CD because the pipeline is meant to execute a bounded task, not hold durable authority. Short-lived OAuth 2.0 tokens reduce the exposure window, but only if issuance is tied to the workload identity, scope is tightly constrained, and the credential cannot be reused outside the intended job context.

Practical implication: Treat embedded CI/CD secrets as an exposure problem and replace them with task-scoped, short-lived credentials.

How OAuth 2.0 token scoping limits GitLab access

OAuth 2.0 is an authorisation framework, so the security value comes from what the token can do, where it can be used, and for how long. For GitLab API access, that means constraining the token to the minimum permissions needed for the pipeline step, rather than granting broad repository or account-level access. The operational benefit is narrower blast radius if the token is stolen, logged, or passed into another tool. The governance requirement is equally important: scope must be explicit, approval must map to the workload, and revocation must be predictable when the pipeline role changes.

Practical implication: Map each pipeline job to the smallest possible GitLab scope and enforce revocation when that job or role changes.

Why pipeline identity needs lifecycle control

A CI/CD pipeline is not a person, but it still has identity lifecycle events: onboarding, permission changes, rotation, and retirement. If those stages are not managed, the pipeline accumulates access the same way a dormant service account does. That creates offboarding risk when projects end, branches change, or automation is replaced. The deeper issue is governance drift, where the access path outlives the automation that justified it. In NHI terms, the control plane must know which workload owns the token, when it was issued, and when it should no longer be valid.

Practical implication: Put CI/CD pipelines into the same lifecycle governance workflow you use for other non-human identities.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

CI/CD pipeline access should be governed as workload identity, not as a tooling exception. The article's core value is not the token format itself, but the decision to treat pipeline access as identity-driven and scoped. That shifts the conversation from secret storage to authorisation design, which is where most CI/CD risk is actually created. Practitioners should read this as a reminder that build systems are NHI actors with their own lifecycle and blast radius.

Short-lived tokens narrow exposure, but they do not solve governance by themselves. A shorter token lifetime reduces the window for reuse, yet the underlying problem remains whether the pipeline is issued only the access it needs and whether revocation is reliable. Without that, short-lived tokens become a partial containment measure rather than a governance control. The practitioner takeaway is to align token lifetime, scope, and ownership together.

Secret sprawl is the named concept this article helps reinforce. Hardcoded credentials in pipelines are part of a wider pattern where secrets escape managed stores and accumulate in code paths, configs, and automation tools. That creates invisible access paths that are harder to audit than formal identity records. The implication for teams is that secret replacement and identity governance have to be handled as one control problem, not two separate projects.

The lifecycle gap is more important than the API detail. GitLab access is only one example of a broader NHI issue: access granted for automation often persists after the workflow changes. That creates residual authority that human IAM programmes frequently miss because the asset is not a person, yet it still needs provisioning, review, and offboarding discipline. Teams should assume any persistent machine credential will eventually become governance debt unless lifecycle controls are explicit.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Secret sprawl will remain the practical blocker for pipeline identity governance. Most teams still have credentials living outside managed stores, so the first programme question is not whether short-lived tokens are available but whether embedded secrets can be found and retired across code, config, and CI/CD systems.

CI/CD access control is converging with workload identity management. The access problem is shifting from a static secret model to one where tokens are issued, scoped, and revoked as part of the workload's lifecycle. Teams that still separate pipeline security from NHI governance will keep missing the real control point.

For practitioners

• Replace embedded pipeline credentials Move CI/CD access to short-lived tokens issued at runtime so build jobs do not carry reusable GitLab credentials in code, config, or pipeline variables.
• Scope GitLab permissions to the job Limit each pipeline token to the exact repository, project, or API action needed for the task, and avoid broad account-level permissions.
• Add pipeline identity lifecycle controls Track which workload owns each token, review access when automation changes, and revoke credentials when a pipeline is retired or replaced.
• Inventory secrets outside managed stores Search code, config files, and CI/CD tools for credentials that bypass secrets managers, then prioritise the highest-risk exposures for rotation.

Key takeaways

• CI/CD pipelines that call GitLab need identity controls designed for workloads, not human users, because hardcoded secrets create standing access risk.
• The biggest governance gap is lifecycle management, since pipeline credentials often outlive the automation they were created for.
• Short-lived, scoped tokens reduce exposure, but only when teams also control issuance, revocation, and secret sprawl across the delivery toolchain.

Key terms

• CI/CD Pipeline Identity: The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
• Short-Lived Scoped Token: A short-lived scoped token is an access credential that expires quickly and only authorizes specific actions or resources. For MCP, it is the practical boundary that replaces standing access with task-limited permission, reducing blast radius when a client or agent is compromised.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.