GitHub Actions policy uploads expose secret handling in CI/CD

At a glance

What this is: Cerbos shows a GitHub Actions pattern for automatically uploading policy files to Cerbos Hub on main-branch pushes using stored credentials.

Why it matters: For IAM and NHI teams, this is a reminder that CI/CD workflows often hold durable secrets and write access that need lifecycle control, not just developer convenience.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Cerbos' guide to automating policy uploads with GitHub Actions

Context

CI/CD automation becomes an identity governance problem when a workflow can read long-lived credentials and use them to write policy changes into another system. In this case, the primary security question is not the YAML syntax, but whether the GitHub Actions runner, repository secrets, and Cerbos Hub credentials are governed as production-grade non-human identities.

That matters because secrets embedded in developer tooling often outlive the operational need that created them. The practical control question is whether the workflow’s access is scoped, rotated, and revoked with the same discipline applied to any other machine identity.

Key questions

Q: How should security teams govern GitHub Actions workflows that use secrets to update policy stores?

A: Treat the workflow as a non-human identity with its own owner, purpose, scope, and revocation path. Limit the job to the minimum permissions needed for policy upload, rotate the underlying credentials on a fixed cadence, and review branch triggers so the workflow cannot be reused outside its intended release path.

Q: Why do CI/CD secrets create more risk than teams often expect?

A: CI/CD secrets become high-risk when they persist across many runs, are stored close to code, and can be reused by automated jobs with write authority. That combination turns convenience into standing privilege, especially when the secret can alter policy, deploy code, or access another system without fresh approval.

Q: What breaks when repository secrets are never recertified?

A: Access drift becomes invisible. Teams lose track of which workflow still needs a credential, whether the permission scope is still valid, and whether the secret survives after the original use case ends. The result is stale automation that can keep acting long after the business owner has moved on.

Q: Who is accountable when a workflow can change authorization policy?

A: The accountable party is the system owner who approved the delegated access, not the automation itself. If a workflow can alter policy, it sits inside the trust boundary for access control and must be subject to the same oversight, logging, and change governance as any other privileged identity path.

Technical breakdown

GitHub Actions as a credentialed execution plane

A GitHub Actions workflow is not just a build script. It is an execution environment that can retrieve repository secrets, start containers, and invoke external systems with those credentials. In this pattern, the workflow uses a client ID and client secret to authenticate a CLI container that replaces files in a remote store. That means the pipeline itself becomes a non-human identity with effective write authority. The risk is not abstract automation, but a durable access path that can be reused whenever the workflow runs on the main branch.

Practical implication: Treat the workflow identity, its secrets, and its allowed branch triggers as governed machine access.

Policy upload pipelines and standing write access

Policy distribution pipelines often look low risk because they move files, not customer data. In reality, they encode standing write access to an authorization source of truth. If the workflow credentials are broad, compromised, or left in place after a team change, an attacker or stale automation can replace policies at runtime. That creates a governance issue across the full lifecycle: issuance, use, rotation, and offboarding. The control failure is not only secret exposure, but unmanaged persistence of authority in a system that is assumed to be routine.

Practical implication: Map policy-upload credentials to an owner, expiry, and revocation path before allowing unattended updates.

Repository secrets are still identity assets

Secrets stored in GitHub repositories are often treated as configuration, but they are credentials with identity semantics. A client ID and client secret pair defines who or what may act, for which store, and with what scope. When these values are placed in Actions secrets and consumed in a container, they become part of a delegated trust chain that extends from developer repository to pipeline runner to third-party service. That chain needs the same scrutiny as any other service account path, including least privilege, rotation, and auditability.

Practical implication: Inventory repository secrets as identities, not settings, and recertify them on the same cadence as service accounts.

NHI Mgmt Group analysis

CI/CD workflows are now identity-bearing execution paths, not neutral automation. A GitHub Actions job that reads repository secrets and writes to an external store is operating as a machine identity with delegated authority. That authority can persist across code changes, team turnover, and branch automation long after the original purpose is forgotten. The implication is that pipeline governance belongs inside identity governance, not beside it.

Repository secrets are only safe when their lifecycle is shorter than their exposure surface. The moment a client secret is reusable across workflow runs, it becomes a standing credential rather than an ephemeral control. That is the same failure mode NHIs create everywhere else: access that is easy to issue and hard to retire. Practitioners should treat every CI/CD secret as a lifecycle-managed asset with ownership, rotation, and revocation.

Policy distribution tools deserve the same least-privilege review as production service accounts. A workflow that can replace files in a policy store can alter authorization outcomes, even if it never touches customer data directly. That makes the store credentials part of the decision layer, not just the deployment layer. The operational conclusion is simple: if the pipeline can change policy, it is part of the trust boundary.

Secrets sprawl inside developer tooling is a governance debt, not a tooling quirk. NHIMG research shows 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools. Cerbos’ pattern sits squarely in that risk zone because it relies on repository-managed credentials to automate write access. The practitioner takeaway is to identify every workflow secret as a governed NHI before it becomes an incident path.

From our research:

• 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.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For the governance baseline behind this pattern, see Ultimate Guide to NHIs , Static vs Dynamic Secrets.

What this signals

GitHub Actions secrets should be planned as identity lifecycle objects, not developer convenience. When a workflow can authenticate to a policy store, its credentials should be owned, reviewed, and retired like any other privileged machine identity. That is especially true when the same secret can be reused across many main-branch runs and the policy surface is security-critical.

The broader programme signal is that CI/CD now sits inside the access governance perimeter. Teams that already struggle with secrets sprawl in code and config will need a cleaner split between build automation and privileged policy change, or they will keep leaking trust into places that are hard to audit.

For teams building their baseline, the OWASP Non-Human Identity Top 10 is a useful companion reference for branch-triggered workflows, secret handling, and privilege scope in automated pipelines.

For practitioners

• Classify the workflow as a governed machine identity Assign an owner, purpose, and access scope to each GitHub Actions workflow that can authenticate to external systems. Document which repository, branch, and environment it may use, and treat the workflow secrets as lifecycle-managed credentials rather than generic configuration.
• Replace long-lived credentials with narrow, revocable access Use the smallest possible permission set for policy upload jobs, then rotate or revoke credentials whenever the repository, store, or deployment process changes. If the workflow only needs upload rights, avoid broader read or administrative permissions that extend the blast radius.
• Separate policy publishing from routine build automation Put policy replacement behind a dedicated approval and audit path, especially when the job can change authorization behaviour. A policy pipeline should be easy to observe, easy to trace, and easy to disable without disturbing unrelated developer workflows.
• Recertify repository secrets on a fixed lifecycle cadence Review every repository secret that supports automation, confirm that it is still needed, and remove any credentials no longer tied to an active business process. Revalidate secrets after team changes, store changes, and policy model updates so stale access does not survive the workflow that created it.

Key takeaways

• GitHub Actions workflows that upload policies are identity-bearing automation and should be governed as such.
• The key risk is standing credential reuse in CI/CD, which extends the blast radius of a routine pipeline job.
• The control answer is lifecycle management for workflow secrets, with narrow scope, rotation, and revocation tied to ownership.

Key terms

• GitHub Actions workflow identity: The effective identity a workflow assumes when it reads secrets, runs jobs, and calls external systems. It is not a person, but it still has scope, privilege, and accountability. In governance terms, it should be reviewed like any other machine identity that can affect production controls.
• Standing credential: A credential that remains valid across repeated executions until someone rotates or revokes it. Standing credentials create ongoing access risk because they can be reused by automation long after the original task is complete, especially when stored in repositories or CI/CD systems.
• Policy publishing pipeline: An automated path that moves authorization policies from source control into a live enforcement store. Because it can change access decisions, it sits close to the trust boundary and needs change control, auditability, and revocation handling, not just build reliability.
• Repository secret: A credential stored for use by code or automation inside a repository context. Repository secrets are identity assets, not configuration text. They should be owned, scoped, rotated, and removed with the same discipline applied to service accounts and other privileged non-human identities.

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 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 automatically uploading Cerbos policies to Cerbos Hub from GitHub Actions. Read the original.