Security teams should bind approval to an immutable commit SHA, not a mutable branch or issue comment. Use event payloads that carry the reviewed code state atomically, and remove any bot permission that can rewrite workflows or promote forked code into trusted branches. That prevents a bot from acting on stale intent and inserting a side-door workflow.
Why This Matters for Security Teams
Maintainer approval in CI/CD is supposed to separate human intent from automated execution, but bots can collapse that gap when approval is tied to mutable state. If a pipeline trusts a branch name, issue comment, or delayed webhook instead of the exact commit that was reviewed, an attacker can swap the code after approval and before execution. NIST control guidance on change control and access enforcement in NIST SP 800-53 Rev 5 Security and Privacy Controls maps directly to this problem: approval must be bound to the asset that is actually released.
The practical risk is not just unauthorized code promotion. A race condition in pipeline gating can also let a bot inject a workflow file, alter build steps, or promote a forked change into a trusted release path after review has already occurred. That turns approval into a false signal and defeats segregation of duties. In environments with pull request automations, release bots, and self-hosted runners, the security boundary is often the event payload itself, not the repository UI. In practice, many security teams encounter this only after a routine release starts executing code that was never the subject of the original review.
How It Works in Practice
The safest pattern is to treat approval as a decision over an immutable object, usually the exact commit SHA and the pipeline inputs resolved at that point in time. The build or deploy job should consume a signed or otherwise integrity-protected event payload that includes the reviewed revision, the repository identity, and the approval context. If the referenced SHA no longer matches the branch tip, the job should fail closed and require a fresh review.
Operationally, teams should separate three things: who may approve, what was approved, and what the automation is allowed to do after approval. That usually means:
- Using branch protection plus required reviewers, but never relying on branch names alone.
- Disabling bot permissions that can rewrite workflow files, alter protected paths, or retarget release jobs.
- Validating that the pipeline runs against the reviewed commit, not a later merge result or cached workspace state.
- Limiting token scope so a bot can open or label work items without gaining promotion rights.
- Recording the approval event and the commit digest in the audit trail for later verification.
This also intersects with identity and privilege governance. A bot is effectively a non-human identity with execution authority, so its permissions should follow least privilege and be reviewed like any other privileged actor. Guidance from the CISA secure software development resources reinforces the need to control code provenance, workflow integrity, and release permissions together. These controls tend to break down when pipelines reuse mutable artifacts or when a shared runner executes jobs across multiple trust zones because stale state can outlive the approval check.
Common Variations and Edge Cases
Tighter approval binding often increases release friction, requiring organisations to balance deployment speed against the cost of re-approval and stricter automation limits. That tradeoff is real, especially in fast-moving repositories where rebasing, merge queues, and ephemeral environments are common. Best practice is evolving, but the current guidance is clear: if the approval does not name the immutable code state, it is not a reliable control.
Edge cases usually appear in hybrid workflows. For example, some teams approve a pull request and then let a bot merge or promote the change later. If the bot can re-resolve dependencies, regenerate manifests, or update workflow files after the approval event, the reviewed state has already drifted. The same risk appears when release automation consumes artifacts from a previous job without verifying provenance. In those cases, security teams should require attestation or digest verification before promotion and should treat any post-approval mutation as a new change requiring review.
For highly regulated environments, the control objective aligns with change integrity, segregation of duties, and auditability more than with any single tool feature. The key question is whether the pipeline can prove that the deployed code is exactly what the maintainer approved. Where repository automation, forked contributions, and shared runners are all present, that proof is hardest to sustain because the approval boundary and the execution boundary drift apart.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF 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 | Least privilege limits what bots can do after approval. |
| NIST AI RMF | AI-style autonomous execution needs governance over action boundaries. | |
| OWASP Non-Human Identity Top 10 | Bots are non-human identities that need lifecycle and privilege controls. | |
| NIST SP 800-53 Rev 5 | CM-3 | Change control prevents post-approval workflow tampering. |
| MITRE ATT&CK | T1195 | Supply chain compromise covers malicious changes in build and release paths. |
Define accountable decision boundaries for automation and verify each action against approved context.
Related resources from NHI Mgmt Group
- How should security teams prevent 403 errors in CI/CD pipelines?
- How should security teams implement asynchronous code controls in CI/CD pipelines to avoid race conditions and hidden failures?
- How should security teams prevent malicious Docker images from entering CI/CD pipelines?
- How should security teams prevent CI/CD pipelines from treating build failures as successful releases?
