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

At a glance

What this is: This is a cookbook on securing CI/CD access to the GitLab REST API with short-lived OAuth 2.0 tokens and identity-based scoped access.

Why it matters: It matters because CI/CD pipelines are non-human identities, and the same lifecycle, privilege, and secrets controls used for service accounts must now be applied consistently to build automation.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Aembit's guide to secure CI/CD access to the GitLab REST API

Context

CI/CD pipeline identity is a non-human identity problem, not just a build engineering problem. When pipelines authenticate to GitLab with long-lived secrets, the real issue is that access survives longer than the work it was created for, which creates standing privilege and exposure across the delivery chain.

The shift to short-lived OAuth 2.0 tokens narrows that exposure window, but it does not remove the need for governance. Teams still have to decide who can mint pipeline access, what scope the token carries, how quickly it expires, and how revocation is handled when pipeline trust changes.

For identity programmes, this sits squarely at the intersection of workload identity, secrets management, and lifecycle control. The source article is focused on implementation patterns, but the governance question is broader: how do you make automated delivery access ephemeral enough to be defensible?

Key questions

Q: How should security teams secure GitLab access from CI/CD pipelines?

A: Security teams should assign each pipeline a distinct workload identity, issue short-lived credentials at runtime, and scope those credentials to the exact GitLab actions required. They should also log issuance and revocation, because pipeline access is an identity lifecycle problem, not just a deployment detail. Hidden or shared secrets should be treated as a control failure.

Q: Why do hardcoded credentials in CI/CD pipelines create so much risk?

A: Hardcoded credentials create standing access that outlives the job, the team, and sometimes the project itself. If the secret is copied into code, logs, runners, or config files, revocation becomes slow and uncertain. That makes pipeline compromise easier to turn into broader access, especially when the same secret is reused across multiple environments.

Q: What breaks when pipeline credentials are not tied to lifecycle controls?

A: What breaks is accountability. Without ownership, expiry, and revocation, a pipeline token becomes a persistent trust relationship that no one is actively managing. Teams lose the ability to prove who can still use the credential, which workflows depend on it, and whether the access should still exist after changes in code, ownership, or infrastructure.

Q: How do teams know if CI/CD secret controls are actually working?

A: They should be able to answer three questions quickly: where every pipeline secret exists, who owns the identity behind it, and how fast it is revoked when a workflow changes. If a team cannot produce those answers, the control is mostly inventory, not governance. Effective controls leave a clear issue, expiry, and offboarding trail.

Technical breakdown

Why short-lived OAuth 2.0 tokens change CI/CD authentication

Short-lived OAuth 2.0 tokens reduce the time a pipeline can use an exposed credential, which makes them materially safer than hardcoded API keys or static personal tokens. In CI/CD, the important distinction is not just authentication method, but credential lifetime and scope. A pipeline that requests a narrowly scoped token at runtime creates a smaller attack surface than one carrying a reusable secret across jobs, runners, and environments. The control value comes from limiting both duration and privilege so that compromise becomes harder to translate into persistent access.

Practical implication: replace long-lived pipeline secrets with runtime-issued, narrowly scoped credentials wherever the API supports it.

How identity-based scoped access differs from secret reuse

Identity-based access assigns permission to the pipeline as an accountable workload identity rather than embedding secrets inside code or configuration. That matters because secret reuse turns every copy of the token into a new trust point, while scoped access lets the authority sit behind policy and issuance rules. For GitLab API workflows, the difference is between a credential that can be copied anywhere and a token that is valid only for the specific workflow, target, and window it was created for. That is the core control shift.

Practical implication: map each pipeline to a distinct workload identity and constrain its permissions to the exact GitLab actions it must perform.

Why secrets in CI/CD remain a governance problem

Secrets in pipelines become a governance problem when teams treat them as implementation details instead of governed identities. Once a token is stored in code, a variable group, or a runner secret store without lifecycle review, the organisation has no clean offboarding path and no reliable revocation trigger. That is why static credentials persist after projects end and why exposed tokens remain exploitable long after discovery. The issue is less about where the secret lives and more about whether the access it represents has a managed lifecycle.

Practical implication: tie every CI/CD credential to an owner, an expiry, and a revocation process before it is permitted in production workflows.

NHI Mgmt Group analysis

CI/CD pipelines are workload identities, not temporary implementation artefacts. Once a pipeline can call GitLab, it is exercising a persistent identity relationship even if the job itself is short-lived. That means the same governance questions used for service accounts apply here: who owns the identity, what it may access, and how it is revoked when the workflow changes. Practitioners should treat pipeline access as part of identity inventory, not build tooling.

Hardcoded credentials in delivery systems create avoidable identity blast radius. The problem is not only exposure if a secret leaks, but also how far that secret can travel across repos, runners, and automation layers before anyone notices. A short-lived token model reduces blast radius by making access narrower in time and scope. The implication is that secrets exposure must be governed as an identity lifecycle issue, not a repository hygiene issue.

Secretless delivery patterns sharpen, rather than replace, access governance. Moving away from embedded credentials does not eliminate authorisation decisions, it moves them into issuance, scope, and trust policy. That is why Zero Standing Privilege thinking fits CI/CD so well: access should exist only for the job that needs it and should disappear when the job ends. Practitioners should align delivery access with ephemeral privilege, not static trust.

Identity governance for automation fails when pipelines are exempt from review. A workflow that can still reach production APIs after the team that created it has moved on is an access governance failure, not a tooling failure. The right lens is lifecycle control for machine identities, including ownership, expiry, recertification, and offboarding. Teams should fold CI/CD identities into the same governance cadence they use for other NHIs.

From our research:

• From our research: 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For deeper context, see Guide to the Secret Sprawl Challenge for how secret exposure expands across code, config, and CI/CD tooling.

What this signals

Secretless pipelines only work when identity governance is treated as part of delivery design. Teams that move to short-lived tokens still need ownership, expiry, and offboarding, otherwise the workflow simply shifts from visible credential sprawl to invisible access sprawl. A practical programme should measure how quickly pipeline identities can be revoked after a codebase, runner, or team changes hands.

Identity blast radius is the right metric for CI/CD governance. The goal is not merely reducing the number of secrets, but shrinking how much damage any one pipeline identity can do if it is misused. That is where workload identity policy, scoped authorization, and revocation discipline intersect with broader Zero Trust thinking. For standards context, practitioners can align this work with the SPIFFE workload identity specification when they need a portable model for ephemeral workload trust.

Hidden pipeline credentials often outlive the systems they were meant to protect. Once build jobs, runners, and automation accounts are left outside review cycles, access persists after the business context has moved on. Teams should treat CI/CD identities like any other NHI population and look for drift in issuance, scope, and revocation coverage.

For practitioners

• Inventory pipeline identities and their API scopes Map every CI/CD workflow that reaches GitLab or other external systems, then record the identity, owner, scope, and expiry for each one. Treat the inventory as part of NHI governance, not a separate DevOps register.
• Replace long-lived secrets with runtime-issued tokens Use short-lived OAuth 2.0 tokens or equivalent workload credentials so that access is minted only when the job runs. Pair that with least-privilege scopes and remove any fallback to embedded API keys or shared runner secrets.
• Add offboarding to pipeline lifecycle management When a project ends, a runner is retired, or a team changes ownership, revoke the pipeline's credentials and remove the trust path immediately. Offboarding should be an explicit step in change control, not an afterthought handled during incident response.
• Review CI/CD secrets outside the repository Search runners, variable stores, build logs, and config files for credentials that never should have been placed there. The goal is to eliminate hidden persistence points, because the secret store is only effective if teams actually use it.

Key takeaways

• CI/CD pipeline access to GitLab should be governed as a workload identity problem, not left as ad hoc build scripting.
• Short-lived tokens reduce exposure, but lifecycle control and scoped authorization are what make the access model defensible.
• If teams cannot inventory, revoke, and recertify pipeline identities, they still have standing privilege hiding inside automation.

Key terms

• Workload Identity: A workload identity is the machine-level identity used by software, pipelines, or services to authenticate to other systems. It should be governed like any other identity, with ownership, scope, expiry, and revocation, rather than treated as a disposable implementation detail.
• Short-Lived Token: A short-lived token is a credential issued for a limited time and a narrow purpose. Its value comes from reducing the window in which exposed credentials can be abused, especially in automation where static secrets tend to persist longer than the task they were meant to support.
• Standing Privilege: Standing privilege is access that remains available whether or not it is actively needed. In CI/CD and other NHI contexts, it creates unnecessary exposure because the credential can be reused outside the intended job or time window, increasing the blast radius of misuse.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, configuration, logs, runners, and tooling. It weakens governance because the organisation loses track of where credentials live, who can use them, and how quickly they can be removed when they are no longer needed.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Aembit: Aembit Server Workload Cookbooks Series | GitLab. Read the original.