Because they create standing privilege inside automation. A write-capable secret can be reused every time the workflow runs, so the control problem becomes who can use, expose, or replace that credential, not just who can edit the workflow file.
Why repository secrets turn deployment workflows into standing-access problems
Repository secrets change the trust model of CI/CD because the workflow no longer depends only on source control permissions. Once a secret is available to an automated runner, every execution becomes a chance to use that credential, which expands who can indirectly exercise it, where it can leak, and how hard it is to prove that use was intended.
That matters in policy deployment because the workflow is usually written to change security controls, infrastructure, or configuration at speed. If the secret can write to the target system, the automation path itself becomes a privileged access path, so compromise of the workflow, the runner, or the secret store can become an access-control failure.
In practice, the risk is not limited to editing the repository. A secret can be exposed through logs, forks, compromised dependencies, runner compromise, or overly broad workflow triggers, and once exposed it is often reusable until rotated. NHIMG’s Guide to the Secret Sprawl Challenge is useful background here because it shows how CI/CD secret exposure and remediation problems reinforce one another.
Where the access-control boundary actually fails
The key failure is that the secret is usually more powerful than the human who edits the pipeline. A contributor may only need permission to open a pull request, but if the workflow can retrieve a write-capable token at run time, the effective privilege sits inside the automation path, not just in Git permissions.
That creates a mismatch between code review and access control. Reviewers can inspect the workflow file, but they may not see how the secret is injected, which jobs can reach it, which environments inherit it, or whether the same credential also works outside the intended deployment target.
NHIMG’s API Key Management Guide is relevant because the same lifecycle problem applies to any deployment credential: scope, revocation, and blast radius matter more than whether the secret is hidden in a repository setting.
When policy deployment uses long-lived secrets, the control plane also becomes harder to monitor. Every successful run can look legitimate, which makes it difficult to distinguish normal deployment activity from abuse unless the workflow, the target system, and the secret issuance model are tightly constrained.
What this means for secure pipeline design
CI/CD secrets should be treated as standing privilege unless the workflow has a strong, short-lived alternative. If a repository secret can deploy policy repeatedly without re-approval, then the real question is not “who can edit the file?” but “who can cause this credential to be used, and under what conditions?”
That is why secrets used for deployment should be narrowly scoped, environment-bound, and easy to replace. Where possible, short-lived tokens or workload identity reduce the persistence of the credential itself, which limits the window in which a leaked secret remains useful.
NHIMG’s Secrets Management Guide is a good companion reference because it frames the practical move away from static secrets toward rotation and secretless patterns.
Policy deployment is also one of the cases where human review alone is not enough. The workflow should make privilege visible in the pipeline design, not hidden in a secret store, and the deployment path should be bounded so that compromise of one repository does not automatically grant broad write access elsewhere.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | CI/CD repository secrets create reusable standing access in workflows. |
| NHI-02 — Secret Leakage | Repository secrets can leak through logs, runners, forks, or compromised jobs. | |
| NHI-05 — Overprivileged NHI | Deployment secrets often grant more target access than the workflow needs. | |
| Recommendation — Replace long-lived deployment secrets with short-lived credentials and tighten rotation. Prevent secret leakage with masking, scoping, and log review controls. Reduce deployment credential scope to the minimum write permissions required. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Deployment secrets need lifecycle control, rotation, and revocation. |
| AC-6 — Least Privilege | Policy deployment credentials should only allow the narrowest required actions. | |
| Recommendation — Manage secret issuance, rotation, and revocation under a formal lifecycle. Limit each pipeline credential to the smallest effective set of deployment rights. | ||
| CIS Controls v8 | CIS-5 — Account Management | Repository secrets effectively function as accounts in automation workflows. |
| Recommendation — Inventory and control automation credentials with the same rigor as user accounts. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Repository secrets alter how access to deployment targets is granted and governed. |
| Recommendation — Define and enforce who may obtain and use deployment credentials. | ||
| OWASP ASVS | V8 — Authorization | The workflow’s secret determines whether deployment actions are authorized. |
| Recommendation — Verify that automation can only perform the deployment actions it is meant to perform. | ||
Practitioner Guidance
What to verify: Confirm whether the secret can write directly to production or only to a narrow deployment target. If it can change policy, configuration, or infrastructure without an independent approval step, treat it as operationally equivalent to a standing admin path.
Decision rule: If the same secret is reusable across runs, rotate it aggressively and replace it with a short-lived credential or federated mechanism before expanding the workflow further. If rotation is not practical, constrain the workflow so the secret cannot reach unrelated environments or repositories.
Common mistake: Teams often secure the repository but ignore the runner and the downstream API. That leaves the secret exposed to logs, job output, compromised actions, and any user who can trigger the workflow in an unexpected context.
Practitioner takeaway: In CI/CD, a secret is not just an implementation detail, it is an access-control decision. The safer design is the one where compromise of the workflow does not automatically become durable write access to the systems being deployed.
Related resources from NHI Mgmt Group
- Why do unsafe pull request workflows increase the risk of secrets theft in CI/CD pipelines?
- Why do pull_request_target and fork-based workflows increase the risk of secrets exposure in CI/CD pipelines?
- What breaks when malicious workflows can read repository secrets in CI/CD pipelines?
- What fails when CI/CD workflows can access secrets and publishing tokens?