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

At a glance

What this is: This guide explains how to auto-upload Cerbos policies from GitLab CI/CD to Cerbos Hub and shows where the secret-handling risk sits in that workflow.

Why it matters: It matters because IAM and security teams must treat pipeline variables, runner access, and policy publishing rights as governance controls, not just build settings.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Cerbos' guide to GitLab CI/CD policy uploads for Cerbos Hub

Context

GitLab CI/CD pipelines are often used to move operational changes into production, but they also become identity enforcement points when they handle credentials that can publish, replace, or revoke policy artifacts. In this case, the primary risk is not the upload step itself, but the fact that policy delivery depends on long-lived secrets stored in pipeline variables and exposed to shared runner execution.

For IAM teams, the question is whether a build pipeline should ever hold standing authority to publish security policy into an external control plane. Once that path exists, the programme has to govern not only code changes but also secret storage, branch protection, and who can trigger policy deployment.

The source article is a practical GitLab workflow guide, but the governance issue is broader than Cerbos Hub. Any CI/CD-driven policy distribution model creates an NHI control problem if the credentials that perform the upload are not tightly scoped, rotated, and monitored.

Key questions

Q: How should security teams govern CI/CD jobs that publish security policy?

A: Treat the publishing job as a privileged non-human identity, not a build task. Scope its credential to one action, protect the variables that hold it, and restrict execution to approved branches and trusted runners. If policy publication changes authorisation behaviour, it belongs in IAM oversight and audit scope, not only in DevOps controls.

Q: Why do CI/CD pipelines create secret governance risk?

A: Because they combine stored credentials, automated execution, and broad operational access in one place. If a pipeline can read a secret and use it to perform a privileged action, the secret becomes a standing access path. That risk grows when variables, logs, artifacts, or runner environments expose the credential beyond the intended job.

Q: What do teams get wrong about branch protection and policy deployment?

A: They often assume branch protection also protects the downstream action. It does not. A protected branch can limit who merges code, but a broadly available deployment secret can still publish policy changes if the job runs. Effective control needs both change approval and runtime credential restriction.

Q: How can organisations tell whether CI/CD policy publishing is under control?

A: Look for separate ownership of the publishing credential, restricted runner execution, complete job logging, and periodic review of who can change the pipeline rules. If the same secret is reused across environments or the job can run from untrusted branches, the control is not working as intended.

Technical breakdown

Pipeline variables as non-human identities

GitLab CI/CD variables behave like operational secrets when they carry client IDs and client secrets. In this pattern, the pipeline job becomes a non-human identity with the ability to authenticate to Cerbos Hub and perform an administrative action on behalf of the repository. The real control boundary is not the YAML file, but the combination of variable exposure, runner trust, and branch rules. If the same credentials can be reused outside the intended pipeline context, the deployment path becomes a standing access path rather than a controlled release mechanism.

Practical implication: Treat CI/CD variables that publish policy as privileged NHI credentials and scope them to the narrowest possible deployment path.

Shared runners and secret exposure

Shared runners execute jobs in a multi-tenant environment, so the trust model depends on how securely secrets are injected and whether job output, environment variables, or container layers can leak them. When a pipeline mounts the repository into a container and passes upload credentials through environment variables, the security posture depends on runner isolation and log hygiene. This is a classic CI/CD secret-handling pattern, not a Cerbos-specific issue. The control question is whether the pipeline can be abused to read, replay, or exfiltrate the same credentials that are meant only for policy publishing.

Practical implication: Limit which runners may execute publishing jobs and block secret exposure through logs, artifacts, and inherited environment state.

Branch-based policy publishing and change control

Triggering policy publication only on the main branch creates a release gate, but it is not a governance boundary by itself. Branch protection controls who can merge code, while the pipeline still decides when the publishing step runs and which secrets it can access. That means the deployment model needs both source control discipline and identity controls around the publishing credential. If either side is weak, policy changes can move from code review into operational authority faster than reviewers can inspect the downstream effect.

Practical implication: Pair branch protection with separate approval and audit controls for any job that can alter production policy state.

NHI Mgmt Group analysis

CI/CD policy publishing creates a standing NHI control surface. A pipeline that uploads policy is not just an automation convenience, it is a non-human identity with write access to a security control plane. The governance problem is that the publishing credential outlives the individual change and can be reused outside the intended deployment event. Practitioners should treat policy publishing secrets as privileged operational identities, not build metadata.

Secret sprawl is the real failure mode here. The guide assumes the Cerbos Hub client secret can live safely in GitLab variables and shared runner execution. That assumption fails whenever CI/CD becomes the place where sensitive credentials are stored, copied, and reused for operational access. The implication is that policy delivery has inherited the same secret governance problem that has long affected service accounts and API keys.

Branch protection does not equal credential protection. Requiring changes on the main branch helps control code movement, but it does not control who can misuse the upload credential if that credential is broadly available to pipeline jobs. This is the familiar gap between source control approval and runtime authority. Practitioners should separate review of policy content from the identity that is allowed to publish it.

GitLab pipelines extend the blast radius of policy administration. Once a pipeline can replace files in Cerbos Hub, any compromise of the repository, runner, or variable store can turn into policy tampering. That is a governance issue because policy itself is part of the authorisation stack. Security teams should model the upload job as a privileged service account with full lifecycle oversight.

Policy deployment should be governed like production access, not CI housekeeping. The article shows a workable delivery pattern, but the operational reality is that the upload action changes authorisation behaviour. That makes it part of the identity programme, not a side effect of DevOps. Practitioners should classify policy publishing under IAM, NHI governance, and audit scope together.

From our research:

• 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.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Guide to the Secret Sprawl Challenge shows why pipeline-stored credentials require rotation, scoping, and owner accountability, not just masking.

What this signals

Secret sprawl becomes a policy-control issue the moment CI/CD can write to an authorisation store. For teams that rely on GitLab or similar pipelines, the operational signal is simple: if the upload credential is shared, long-lived, or difficult to rotate, the deployment path has become an unmanaged NHI. That is exactly the kind of control surface the OWASP Non-Human Identity Top 10 is meant to surface.

Pipeline-driven policy delivery should be measured like privileged access, not build success. The relevant question is not whether the job ran, but whether the actor that ran it had a bounded purpose, a bounded lifetime, and an auditable owner. When those answers are unclear, the organisation is already carrying credential debt in the release process.

Teams should expect more security tooling to converge on identity-aware software delivery because policy publication is now part of the trust chain. That makes lifecycle review, secret rotation, and runner governance central to NIST Cybersecurity Framework 2.0 implementation rather than peripheral DevOps hygiene.

For practitioners

• Separate publishing credentials from developer workflow Use a dedicated Cerbos Hub client credential only for policy upload jobs, and do not reuse it for testing, local tooling, or other API calls. Treat the credential as a privileged NHI with owner, purpose, and review cycle.
• Harden GitLab variable handling Store the upload secret only in protected, masked variables and restrict access to the minimum projects and branches that need policy publication. Review whether shared runners should be allowed to execute the job at all.
• Add approval gates for policy changes Require code review and explicit approval for changes that affect the upload job, the branch rule, or the target store ID. The pipeline should not be the sole control deciding when security policy is published.
• Audit policy publication as an identity event Log every successful and failed upload, including the branch, actor, runner, and target store. Feed those events into identity and security monitoring so policy changes are traceable like any other privileged action.

Key takeaways

• CI/CD policy uploads turn a release pipeline into a privileged identity path if the publishing secret is not tightly governed.
• The main risk is not the YAML file itself but the credential, runner, and branch model that surrounds it.
• Teams should separate policy approval from policy publication and treat upload secrets as high-value NHI assets.

Key terms

• Policy Publishing Credential: A policy publishing credential is the secret used by an automated system to write or replace authorisation policy in a control plane. It functions like a privileged non-human identity because it can change access behaviour without human interaction, so it requires ownership, rotation, and audit controls.
• Protected CI/CD Variable: A protected CI/CD variable is a pipeline secret restricted to approved branches, environments, or execution contexts. It reduces exposure, but it does not remove the governance obligation to limit scope, mask output, and revoke the secret when its purpose changes.
• Shared Runner: A shared runner is a multi-tenant execution environment that processes pipeline jobs for more than one project or user. It is useful for automation, but it increases the importance of secret isolation, job logging discipline, and trust boundaries because the runner itself becomes part of the security model.

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 Cerbos: GitLab CI/CD policy upload to Cerbos Hub. Read the original.