Standing write permissions widen the blast radius of a workflow compromise. If an attacker reaches code execution, a token with contents write or pull requests write can push commits, alter build logic, or merge malicious changes. Least privilege reduces that impact, and short-lived, narrowly scoped credentials are safer than persistent elevated access.
Why This Matters for Security Teams
CI/CD systems are trusted to build, test, package, and deploy software at speed, which makes their permissions part of the software supply chain trust boundary. When a workflow holds standing write access, a single compromise can shift from limited execution to repository tampering, build poisoning, or unauthorized release activity. That is why current guidance in the NIST Cybersecurity Framework 2.0 and related control sets emphasizes least privilege, strong identity assurance, and continuous monitoring.
The risk is not only accidental misuse. A compromised runner, leaked secret, malicious dependency, or abused third-party action can inherit the workflow’s authority and use it to modify source, inject artifacts, or weaken downstream protections. In supply chain incidents, the harmful change often looks legitimate because it is delivered through normal automation paths. Teams sometimes focus on protecting developer accounts while leaving machine identities and workflow tokens overly permissive.
In practice, many security teams encounter workflow privilege abuse only after a trusted automation path has already been used to alter code or release artifacts, rather than through intentional permission review.
How It Works in Practice
Standing write permissions matter because CI/CD platforms often run with broad, persistent access that outlives a single job. If the workflow can write to the repository, update tags, publish packages, or approve pull requests, then compromise of any step in the pipeline can become a supply chain event. This is especially dangerous when the workflow token is reused across jobs or when secrets are available to untrusted branches, forks, or third-party actions.
Security teams should treat workflow identity as a first-class control surface. The practical goal is to make each build or deployment use the smallest possible permission set for the shortest possible time. That usually means repository scopes like read-only by default, explicit elevation only for jobs that need it, and manual separation between build, test, and release stages. The OWASP Non-Human Identity Top 10 is useful here because CI/CD tokens, runners, and service accounts are all non-human identities that require lifecycle control, secret hygiene, and revocation discipline.
- Use short-lived credentials instead of persistent tokens wherever the platform supports them.
- Scope write access to a single repository, environment, or release action rather than the whole org.
- Restrict secrets to trusted branches and protected environments only.
- Require branch protection, code review, and signed releases for any job that can alter source or artifacts.
- Log and alert on permission changes, unusual workflow triggers, and release-side activity.
The control logic aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially least privilege, access enforcement, and auditability expectations for system and information integrity. These controls tend to break down when CI/CD is shared across many repositories with ad hoc secrets, because permission sprawl makes it hard to prove which workflow can actually write to production assets.
Common Variations and Edge Cases
Tighter workflow permissions often increase operational overhead, requiring organisations to balance deployment speed against release assurance. That tradeoff is real: teams may need more approval gates, separate service accounts, or extra environment design to preserve both agility and control.
Best practice is evolving for reusable workflows, self-hosted runners, and ephemeral build agents, because these components can blur the line between trusted automation and untrusted execution. A workflow that cannot write directly to the repository may still be able to exfiltrate a deploy key, tamper with build metadata, or influence artifact provenance. In those cases, the main question is not just whether the token can write, but whether the workflow can reach a more privileged identity later in the pipeline.
There is also no universal standard for how much write access is acceptable for protected release automation. Some organisations permit narrowly scoped write access for version bumps or release notes, while others require an entirely separate release pipeline with stronger approvals. The right answer depends on how much blast radius the organisation can tolerate, how mature its provenance checks are, and whether its release process can detect tampering before distribution. Where software supply chain risk is high, practitioners should bias toward short-lived elevation, explicit approval, and verifiable artifact integrity rather than permanent workflow authority.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Workflow write permissions should be limited to the minimum required. |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is the core control for reducing workflow blast radius. |
| OWASP Non-Human Identity Top 10 | CI/CD tokens and runners are non-human identities that need lifecycle control. |
Assign only the access each pipeline step needs and remove persistent elevation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
