Topic starter
25/06/2026 10:40 pm
TL;DR: Connecting CI/CD pipelines to the GitLab REST API with short-lived OAuth 2.0 tokens can replace hardcoded credentials and narrow access scope for machine workflows, according to Aembit. The underlying governance issue is bigger than token format: pipeline identity still needs lifecycle control, scoped authorization, and revocation discipline.
Editorial analysis by NHI Mgmt Group, based on content published by Aembit: “Cookbooks Archives”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: CI/CD pipelines that call GitLab need identity controls designed for workloads, not human users, because hardcoded secrets create standing access risk.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 24 hours ago by NHI Mgmt Group
25/06/2026 11:19 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: CI/CD pipeline access to GitLab needs short-lived tokens
This post was modified 24 hours ago by NHI Mgmt Group