Bitbucket policy uploads to Cerbos Hub expose pipeline trust gaps

At a glance

What this is: Cerbos documents a Bitbucket Pipelines workflow that uploads policy files to Cerbos Hub on main-branch pushes, using secured repository variables and client credentials.

Why it matters: It matters because CI/CD pipelines are a common place where non-human identity secrets, branch protections, and write access controls intersect across NHI, autonomous, and human governance.

👉 Read Cerbos' guide to uploading policies from Bitbucket Pipelines

Context

Policy delivery through CI/CD is convenient, but it also turns build automation into an identity control point. In this pattern, the pipeline itself becomes a non-human identity boundary: if the repository variables, branch rules, or upload credentials are mishandled, policy change integrity depends on pipeline hygiene rather than governance design.

Cerbos' guide is a practical example of how application policy distribution now depends on secrets stored in developer tooling. That makes the relevant question less about deployment mechanics and more about who can write, rotate, and observe the credentials that allow a pipeline to publish policies on behalf of the team.

Key questions

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

A: Treat the pipeline as a privileged non-human identity, not as a neutral automation layer. Define an owner, scope its write access narrowly, and require a separate approval path for policy publication. The goal is to prevent build automation from becoming an unreviewed change channel into production controls.

Q: When does a policy deployment pipeline become a governance risk?

A: It becomes a governance risk when the pipeline can change enforcement state with credentials that are not tightly scoped, rotated, and reviewed. If branch protections, repository variables, and access ownership are weak, the pipeline can publish policy faster than your governance process can detect or approve the change.

Q: What do teams get wrong about secrets used in build pipelines?

A: Teams often treat pipeline secrets as disposable setup values rather than administrative credentials. In reality, a secret that can publish policy or modify a control plane object has the same lifecycle and review requirements as other privileged machine identities.

Q: How can organisations reduce the blast radius of policy-upload automation?

A: Limit the upload job to a single repository, a single branch pattern, and a single purpose-built credential. Then rotate that credential when ownership changes, and verify that logs, build artefacts, and shared runners cannot expose the secret or reuse it elsewhere.

Technical breakdown

Bitbucket Pipelines as a non-human identity boundary

A pipeline step that executes on a branch trigger is not just automation, it is an identity-bearing workload with permission to act. In this setup, the container runtime mounts the repository workspace, reads environment variables, and invokes Cerbos Hub upload commands using client credentials. The security boundary therefore sits across Bitbucket repository settings, branch protection, and the downstream hub store permission model. If any of those layers is over-trusted, the pipeline can publish policy changes without a separate human review path.

Practical implication: Treat the pipeline as an NHI with explicit write scope, not as a neutral delivery mechanism.

Secrets handling for policy publication

The workflow relies on two secured repository variables, a store ID, and a read-write client credential pair. That means the security of policy publishing depends on how Bitbucket stores, exposes, and scopes those secrets, plus whether the build environment can leak them through logs, misconfigured scripts, or shared runners. The core risk is not only theft, but reuse: a credential that can upload policies can also become a privileged control plane input if it is copied into another pipeline or repo.

Practical implication: Isolate and rotate the upload credentials, and verify that the pipeline never prints or reuses them outside the intended job.

Branch-triggered policy governance

Main-branch triggering creates a simple release gate, but only if main truly represents approved policy state. The pipeline assumes that branch controls, pull request review, and repository permissions already enforce separation between policy authorship and policy publication. In practice, policy-as-code workflows often blur developer and security ownership unless the approval chain is explicit. The result is that the publish step becomes the last control, rather than a controlled release point.

Practical implication: Require a distinct approval path for policy publication so the upload step does not become an unreviewed privilege escalation path.

NHI Mgmt Group analysis

CI/CD policy publishing is an NHI governance problem, not just a DevOps convenience. When a build pipeline can upload security policy on behalf of the team, it becomes a non-human identity with effective change authority. That means the control question shifts from 'can the pipeline run?' to 'who controls the identity and privilege behind the pipeline?'. Practitioners should treat policy publication as governed execution, not routine automation.

Write-capable pipeline credentials create a control plane risk when they are shared across repositories or jobs. The guide shows a pattern where a client ID and secret are enough to replace files in a hub store. That concentrates authority into a compact secret set, which is efficient but fragile if access is copied, inherited, or left in place after team changes. The relevant discipline is lifecycle governance for non-human identities, because access persists as long as the credentials do.

Branch protection and pipeline permissions are part of the same trust model. A main-branch trigger only adds value if merge review, repository variable protection, and environment scoping all align. If the branch is effectively writable by too many actors, the pipeline becomes a publication shortcut rather than a release gate. Practitioners should view policy-as-code through the same least-privilege lens they apply to other production-changing identities.

Cerbos' workflow illustrates a broader pattern of hidden privilege in modern engineering systems. Many teams classify CI/CD as infrastructure, yet the moment a pipeline can publish policy, rotate configuration, or alter enforcement state, it is exercising administrative identity. That is the point where IAM, PAM, and NHI governance converge. Teams should map these publishing jobs into the same entitlement and review processes used for other high-impact machine accounts.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• For a broader NHI control baseline, compare this with Top 10 NHI Issues, which frames why privileged machine identities need lifecycle ownership and continuous review.

What this signals

Secret-bearing pipelines should be managed as production identities. Once a CI/CD job can publish policy, rotate configuration, or alter enforcement state, the owning team needs the same entitlement review discipline used for other privileged machine accounts. That is especially true when secret remediation still takes a median of 27 days according to The State of Secrets in AppSec, because delayed cleanup turns a build credential into persistent exposure.

Policy publication creates an identity lifecycle obligation. Teams should map upload jobs, release branches, and repository variables into the same governance model used for other NHI assets. The practical shift is from ad hoc pipeline setup to an owned, reviewable access path with explicit offboarding when repositories, teams, or delivery patterns change. For the control baseline, the OWASP Non-Human Identity Top 10 remains a useful reference point.

For practitioners

• Classify the pipeline as a privileged NHI Document the Bitbucket workflow as a non-human identity with specific write authority over policy content and store access, then assign an owner and review cadence to that identity.
• Separate policy authorship from policy publication Require pull request review for policy changes and keep the upload job restricted to a release branch or approved environment so the publishing step cannot be used as a casual bypass.
• Harden repository variables and credential scope Store the client secret as a secured variable, limit it to the single pipeline job that needs it, and rotate it when repository ownership or pipeline logic changes.
• Review pipeline logs for secret exposure paths Check whether the container command, shell expansion, or debug output could reveal CERBOS_HUB_CLIENT_ID or CERBOS_HUB_CLIENT_SECRET in logs or build artefacts.

Key takeaways

• Bitbucket policy-upload pipelines are identity controls in disguise, because they combine execution, secret use, and write authority.
• The main risk is not the YAML file itself, but the privileged credentials and branch trust model that sit behind it.
• Teams should govern policy publication as a lifecycle-managed NHI with scoped access, review gates, and explicit credential ownership.

Key terms

• Non-Human Identity: A non-human identity is any machine or workload credential that can authenticate and act inside an environment. In CI/CD, that includes pipeline jobs, client secrets, tokens, and service credentials. Governance means owning the identity’s scope, lifecycle, and revocation path, not just storing the secret.
• Policy-as-Code Publication: Policy-as-code publication is the act of pushing security rules from source control into an enforcement system through automated delivery. The operational risk is that publishing authority can drift away from policy authorship, so the upload path needs explicit controls, approvals, and accountability.
• Secret Scope: Secret scope is the boundary that defines where a credential can be used and what it can change. Narrow scope reduces blast radius, but only if the credential cannot be copied into other jobs, logs, or repositories. In pipelines, scope should match a single purpose and a single release path.
• Branch Protection: Branch protection is the set of rules that limits who can merge, push, or bypass review on a repository branch. For identity governance, it is part of the trust chain that decides whether a pipeline-triggered change is controlled or simply automated.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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: a guide to uploading Cerbos policies to Cerbos Hub from Bitbucket Pipelines. Read the original.