Topic starter
12/06/2026 12:35 am
TL;DR: Automating policy uploads from GitLab CI/CD centralises policy delivery, but it also places Cerbos Hub client credentials inside pipeline variables and runner execution paths, according to Cerbos documentation. Secret handling, branch controls, and runner trust now become part of the policy deployment model, not just DevOps plumbing.
Editorial analysis by NHI Mgmt Group, based on content published by Cerbos: “Automating Cerbos Policy deployments with GitLab Runners”.
Key questions
Q: What breaks when CI/CD pipelines rely on static secrets?
A: Static secrets create a reusable attack path into production infrastructure.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
12/06/2026 9:54 am
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.
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 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.
👉 Read our full editorial: GitLab policy uploads to Cerbos Hub expose CI/CD secret risk
This post was modified 5 days ago by NHI Mgmt Group