Notifications
Clear all
Topic starter
12/06/2026 12:36 am
TL;DR: Centralising policy delivery by automating policy uploads from Bitbucket Pipelines to Cerbos Hub concentrates trust in pipeline secrets and branch controls, according to Cerbos documentation. For IAM and NHI teams, the issue is not the upload step itself but the access assumptions behind CI/CD variables and write-capable credentials.
NHIMG editorial — based on content published by Cerbos: a guide to uploading Cerbos policies to Cerbos Hub from Bitbucket Pipelines
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Cerbos' full documentation covers the operational detail this post intentionally leaves for the source:
- The exact Bitbucket Pipelines YAML needed to upload policies to Cerbos Hub
- The repository variable setup for CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET
- The Cerbos Hub store credential requirement, including Read & Write permissions
- The end-to-end commit, push, and verification flow inside Bitbucket
👉 Read Cerbos' guide to uploading policies from Bitbucket Pipelines →
Bitbucket policy uploads to Cerbos Hub: what IAM teams should watch?
Explore further
12/06/2026 9:56 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Bitbucket policy uploads to Cerbos Hub expose pipeline trust gaps
