Notifications
Clear all
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.
NHIMG editorial — based on content published by Cerbos: GitLab CI/CD policy upload to Cerbos Hub
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.
Questions worth separating out
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.
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.
Q: What do teams get wrong about branch protection and policy deployment?
A: They often assume branch protection also protects the downstream action.
Practitioner guidance
- 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.
- 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.
- 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.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Exact GitLab CI/CD YAML needed to upload policies into a Cerbos Hub store
- Step-by-step setup of protected and masked CI/CD variables for the upload credential
- The specific command used by cerbosctl to replace policy files in the target store
- The verification flow in GitLab Pipelines after the main-branch push
👉 Read Cerbos' guide to GitLab CI/CD policy uploads for Cerbos Hub →
GitLab policy uploads to Cerbos Hub: what IAM teams should check?
Explore further
12/06/2026 9:54 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: GitLab policy uploads to Cerbos Hub expose CI/CD secret risk
