GitLab policy uploads to Cerbos Hub expose CI/CD secret risk

At a glance

What this is: This guide explains how to automate Cerbos policy uploads from GitLab CI/CD to Cerbos Hub and shows that the workflow depends on client credentials inside the pipeline.

Why it matters: It matters because CI/CD delivery paths can turn policy distribution into a secret-handling problem, which affects NHI governance, runner trust, and least-privilege boundaries.

Context

GitLab CI/CD is a pipeline system for building, testing, and automating software delivery. In this guide, the same mechanism is used to upload Cerbos policies to Cerbos Hub whenever the main branch changes, which makes policy release part of the software delivery path.

The governance gap is that the upload job depends on long-lived client credentials placed into pipeline variables and consumed by runner-executed commands. For identity teams, that means the control problem is not just policy authoring or code review, but how NHI secrets move through CI/CD execution and how much trust is placed in the runner environment.

Key questions

Q: What breaks when CI/CD pipelines rely on static secrets?

A: Static secrets create a reusable attack path into production infrastructure. Once they are copied into workflow files, logs, runner images, or environment variables, a single compromise can expose broad access long after the original job finishes. That is why pipeline secrets should be treated as production identity, not temporary configuration.

Q: Why do CI/CD policy upload jobs increase secret exposure risk?

A: Because the job must place reusable credentials into the execution context of a runner. That creates more places for the secret to exist, including job configuration, environment variables, logs, and build infrastructure, which expands the attack surface beyond the repository itself.

Q: What signs show that a policy deployment pipeline is too trusted?

A: Warning signs include broad write access to the CI file, shared runners used for sensitive uploads, secrets reused across unrelated jobs, and no clear owner for the credentials that publish policy to the central store. Those conditions indicate the pipeline is carrying standing authority without enough governance.

Q: Should teams separate policy upload credentials from general build secrets?

A: Yes. Policy upload credentials should be isolated because they enable direct changes to a control store, which makes them more sensitive than ordinary build-time variables. Separation reduces the chance that a routine build issue, forked pipeline, or unrelated job can reach the policy channel.

Technical breakdown

How GitLab CI/CD policy uploads rely on stored client credentials

The workflow uses a GitLab job to call cerbosctl inside a container and authenticate to Cerbos Hub with CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET. Those values are not ephemeral session tokens. They are reusable credentials passed through environment variables, which means the pipeline becomes a credential-bearing execution path rather than a simple file transfer. Because the job is triggered on the main branch, the trust boundary includes branch rules, pipeline configuration, and the runner that executes the container.

Practical implication: Treat the pipeline as a credentialed NHI path and review whether those secrets need the same controls as other long-lived machine credentials.

Why shared runners and container execution change the risk profile

Shared runners expand the trust surface because the job runs in infrastructure that is not dedicated to a single repository. Even when variables are masked and protected, the credentials still exist at runtime in the pipeline context and can be exposed through misconfiguration, malicious job steps, or runner compromise. This is a classic CI/CD secret exposure pattern: the control plane assumes the pipeline is a safe place to handle credentials, while the execution layer is often broader and less observable than teams expect.

Practical implication: Limit who can modify pipeline jobs and separate release runners from general-purpose build runners.

Why policy deployment becomes an identity governance problem

Uploading policies is not just a DevOps task when the path to deployment includes high-value secrets, branch gating, and remote store access. The deployment model now includes NHI lifecycle questions such as who owns the Cerbos Hub credentials, how they are protected, when they are rotated, and how access is revoked if the pipeline or repository changes. That is identity governance, not only build automation, because the policy store is being updated by a machine identity path with standing authority.

Practical implication: Inventory the credentials used by policy pipelines and place them under the same governance model you use for other machine 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.
• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.

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 policy delivery turns secret handling into part of the control plane. When policy uploads are automated from GitLab, the deployment path inherits the risk of whatever secrets the pipeline must use to authenticate. That makes the pipeline itself a governed identity path, not a neutral transport mechanism. Practitioners should treat pipeline credentials as part of the policy system's security boundary.

Long-lived client credentials are the real governance weak point here. The workflow depends on reusable CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET values, which means the upload path assumes those secrets remain trustworthy across multiple runs. That assumption is fragile in CI/CD because job definitions, runner scope, and branch protections all become potential exposure points. The practical conclusion is that credential ownership and rotation for deployment jobs must be explicit.

Branch protection and runner trust now influence policy integrity. A main-branch-only rule reduces accidental uploads, but it does not remove the need to trust the execution environment that handles the upload. If a pipeline can write policy to a central store, then a compromised job can also become a policy integrity issue. That makes CI/CD governance part of application authorization governance, not a separate concern.

Ephemeral build execution does not eliminate standing authority. The job runs ephemerally, but the credentials it uses are standing. That mismatch creates a governance gap between short-lived execution and long-lived privilege. Teams should recognise that the true control problem is not the container lifetime, but the persistence of the authority that container can exercise.

Policy distribution needs NHI lifecycle discipline, not just repository discipline. The same access review logic used for human admins does not map cleanly to pipeline identities and deployment secrets. What matters is whether the machine identity behind the upload has a clear owner, a bounded purpose, and a revocation path when the workflow changes. That is the discipline practitioners need to operationalise.

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: API Key Management Guide

What this signals

Policy upload jobs should be reviewed as machine identity paths, not just delivery automation. Once a CI/CD pipeline can write to a central policy store, the credentials behind that write path deserve ownership, rotation, and offboarding discipline. Teams that still treat those values as ordinary build variables will miss the governance boundary that actually matters.

Secret exposure is the structural risk, not the container image. The container is only the execution shell; the real question is where the upload authority lives and who can reuse it. That means CI/CD governance, runner trust, and NHI lifecycle controls need to be assessed together rather than in separate silos.

For practitioners

• Harden pipeline secret handling Store Cerbos Hub client credentials as protected variables only where absolutely necessary, and remove them from any job that does not directly perform the upload.
• Restrict who can modify upload jobs Limit changes to .gitlab-ci.yml and the policy upload job to trusted maintainers, because job edits can turn a legitimate release path into a secret exfiltration path.
• Separate release runners from general builds Use a dedicated runner or equivalent isolation for policy uploads so the job does not share execution context with unrelated pipelines or lower-trust projects.
• Rotate upload credentials on a fixed cadence Treat CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET as machine credentials with an owner, rotation date, and revocation procedure tied to repository and pipeline changes.
• Audit policy deployment logs and job output Review pipeline logs for evidence that secrets, store IDs, or upload commands are being exposed through debugging output, failed jobs, or copied configuration.

Key takeaways

• Automated policy uploads through GitLab CI/CD create a machine identity path that depends on reusable credentials, so release automation and identity governance are now linked.
• The main risk is not the policy file itself but the secret-bearing pipeline that can expose or misuse upload authority through runner execution, job edits, or mis-scoped variables.
• Teams should govern policy deployment credentials like other non-human identities, with ownership, isolation, rotation, and revocation tied to the pipeline's trust boundary.

Key terms

• CI/CD secret exposure: CI/CD secret exposure is the accidental or unauthorized disclosure of credentials used by build and deployment pipelines. It includes API keys, tokens, certificates, passwords, and signing material appearing in logs, code, artifacts, environment variables, or pipeline configuration. Exposure creates immediate risk because attackers can impersonate systems, alter releases, or move laterally.
• Pipeline Trust Gap: The mismatch between the trust a build or release system is given and the level of identity governance it actually receives. It appears when CI/CD accounts, signing identities, and automation tokens can change production outcomes without the monitoring, scope limits, or lifecycle controls usually reserved for privileged access.
• Standing Deployment Authority: Reusable access that allows an automated job to perform the same privileged action repeatedly without fresh approval or issuance. This is efficient for delivery but risky for governance because the authority persists beyond any single run and can be abused if the pipeline is altered or compromised.
• Machine Issued Credential Lifecycle: The set of controls that govern creation, review, rotation, and revocation of credentials issued to non-human actors. It matters because initial issuance is only one point in the life of access, and unmanaged persistence is where many identity failures begin.

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.