CI/CD policy uploads expose Cerbos secret-handling assumptions

At a glance

What this is: This is a CI/CD pattern for uploading Cerbos policies from CircleCI to a Cerbos Hub store, and its key issue is that policy publishing depends on long-lived client credentials and write access in the pipeline.

Why it matters: It matters because IAM and NHI teams have to govern build-time secrets and service credentials as production access paths, not as a narrow DevOps implementation detail.

Context

CI/CD policy publishing is a workflow problem only until credentials enter the design. In this pattern, a pipeline on the main branch uses stored client ID and client secret values to authenticate to a remote policy store and perform a write operation, so the real control boundary is the NHI credential set behind the build job.

That matters because the pipeline is acting as a non-human identity with persistent access to a governance control plane. Once the build system can publish policy, the scope, rotation, and revocation of those credentials become part of identity governance, secrets management, and release assurance.

Key questions

Q: What breaks when CI/CD pipelines rely on static secrets?

A: Static secrets create a reusable attack path into production infrastructure. Once they are copied into workflow files, logs, runner images, or environment variables, a single compromise can expose broad access long after the original job finishes. That is why pipeline secrets should be treated as production identity, not temporary configuration.

Q: Why do CI/CD publish credentials increase governance risk?

A: Because the credential is not only proving identity, it is authorising a state-changing action in a control plane. If that secret is reused, overprivileged, or left in place after workflow changes, the publish path can be abused without changing the policy files themselves.

Q: How do teams tell whether a pipeline secret is overprivileged?

A: A pipeline secret is overprivileged when it can do more than the single workflow task it was created for, such as writing to stores outside the intended branch or environment. The clearest signal is when revoking that one credential would interrupt unrelated jobs.

Q: Who should own credentials used by CI/CD policy automation?

A: The system owner, not the individual developer who created the workflow, should own the credentials and the offboarding path. Ownership should include approval, rotation, audit review, and a documented way to disable the job when the repository, project, or vendor relationship changes.

Technical breakdown

How CI/CD policy uploads authenticate to a remote store

The guide shows a CircleCI job launching a container that calls cerbosctl with two environment variables, CERBOS_HUB_CLIENT_ID and CERBOS_HUB_CLIENT_SECRET, plus a store identifier. That means the upload is not just a file copy from the repository. It is an authenticated action performed by a pipeline identity that has been granted write capability to a central policy store. In identity terms, the build job becomes a service actor with standing entitlement, and the security question becomes which controls govern that entitlement over time.

Practical implication: Treat the pipeline job as an NHI that needs scoped authentication, not as an ordinary build step.

Why environment variables are a trust boundary, not a convenience

Environment variables are only a delivery mechanism for the credential values, but they still define where the secret exists and who can retrieve it at runtime. If those values are shared across jobs, inherited into logs, or reused outside the narrow upload step, the pipeline inherits the same exposure and misuse risks as any other long-lived secret. The critical issue is not the upload command itself. It is the assumption that a pipeline-held secret is safe simply because it is stored outside the repository.

Practical implication: Limit secret exposure to the narrowest job scope and treat any reusable pipeline credential as a governed secret, not a config detail.

Main-branch uploads and policy authority

Restricting uploads to the main branch reduces accidental changes, but it does not solve credential abuse if the branch pipeline is compromised or if the stored credentials are overprivileged. The policy store becomes authoritative only if the identity used to publish to it is tightly controlled. In practice, that means the access model for policy publication must be evaluated like any other privileged machine-to-machine path, with explicit lifecycle and revocation ownership.

Practical implication: Review who can alter the branch workflow and who can revoke the publish credential when trust changes.

Breaches seen in the wild

• CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy publishing through CI/CD is an NHI control plane, not a build convenience: The moment a pipeline can write policies to a central store, it is exercising non-human identity authority over security decisions. That authority depends on credential scope, branch protection, and runtime containment, not on the policy language itself. Practitioners should therefore classify the upload path as governed machine access, not a low-risk deployment helper.

Long-lived client credentials create release-time trust debt: A pipeline secret that can publish policy is a standing privilege, even if the job runs only on main-branch changes. That privilege persists across commits, reviewers, and code changes until someone rotates or revokes it. The practical conclusion is that release automation must be audited as credential governance, because its blast radius extends beyond the repository.

Secret handling assumptions collapse when the same identity can both build and publish: The assumption that CI/CD secrets are merely transport credentials was designed for a narrower condition, where the pipeline only moved artifacts. That assumption fails when the actor can independently push authoritative policy into a live store because the credential now carries governance power. The implication is that teams must rethink which actions are safe to delegate to the pipeline at all.

Named concept: policy publication privilege drift: This pattern shows how a narrow automation task can accumulate authority over time until the pipeline effectively owns the policy change path. The drift is subtle because it starts as convenience and ends as persistent write access to a control plane. Practitioners should track policy publishing the way they track privileged service accounts: with explicit ownership, scope, and revocation review.

CI/CD identity governance belongs in the same control stack as secrets management: The article links code promotion, secret storage, and write access into one operating path. That means the relevant controls span OWASP-NHI, NIST CSF access permissions, and standard secrets lifecycle discipline, not just repository hygiene. Teams that separate these controls will miss the shared failure mode: a build identity with more authority than its workflow needs.

From our research library:

• 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.
• 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.
• Read next: Secrets Management Guide

What this signals

Policy publication privilege drift: When a pipeline can write policy to a live store, the build job becomes a governed identity with standing authority. That authority should be reviewed like any other privileged service account, because the risk is not the upload command but the persistence of its secret-backed access.

CI/CD secrets often outlive the workflow that created them, so branch changes, environment changes, and ownership changes must trigger lifecycle review. Access that can alter policy should be treated as release-critical entitlement, with revocation paths as visible as deployment paths.

For practitioners

• Constrain policy-upload credentials to one job Issue a dedicated publish identity for the upload step and scope it only to the Cerbos Hub store action required by the workflow. Do not reuse the same credentials for other build or deployment tasks.
• Rotate credentials on workflow or ownership changes Treat the client ID and client secret as governed NHI secrets with explicit rotation triggers when branch protections change, project ownership changes, or the pipeline is refactored.
• Review who can modify the CircleCI pipeline Separate repository write access from publish authority so that editing the config file does not automatically grant policy publication capability through inherited environment variables.
• Audit the upload path for secret exposure Check whether the build job exposes credentials in logs, child processes, or shared environment scope, and remove any unnecessary inheritance before the pipeline can write to the store.

Key takeaways

• CI/CD policy uploads are only as safe as the secret and scope model behind them, because the pipeline itself becomes a privileged identity.
• Most organisations still store secrets outside secrets managers in vulnerable places such as code, config files, and CI/CD tools.
• Teams should govern policy-publishing credentials with the same lifecycle discipline they apply to other machine identities, including scope review and revocation.

Key terms

• CI/CD Pipeline Identity: The machine identity used by continuous integration and deployment systems to authenticate to code repositories, registries, and cloud environments during automated build and deployment.
• Client Secret: A client secret is a credential used by an application to prove its identity to an identity provider during token exchange. In OIDC, it functions like a password for the workload, so exposure in code, logs, or build artifacts can enable impersonation and downstream access.
• Policy Publication Authority: The permission to write or replace security policy in a live store or control plane. This is a governance-sensitive entitlement because it changes enforcement behaviour, not just configuration state, and therefore needs stronger review and revocation controls than ordinary file access.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

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 building or maturing an IAM programme, it is worth exploring.