Configure environment protection rules and approval gates
Implementation Effort: Medium – Defining required reviewers, branch restrictions, and checks on each protected environment across GitHub and Azure DevOps takes coordinated setup with resource owners.
User Impact: High – Every deployment to a protected environment now waits on approvals and checks, so all teams that ship to those targets need advance notice.
Lifecycle Stage: Deploy
Overview
Configure environment protection rules and approval gates so every deployment to a sensitive target is checked against approvals, branch controls, and environment-specific validations before the pipeline can proceed. This task addresses OWASP CICD-SEC-1 (Insufficient Flow Control) through deployment gates and OWASP CICD-SEC-5 (Insufficient PBAC) through scoped environment permissions.
Environment protection rules establish mandatory checkpoints that must be satisfied before a pipeline can deploy to a given target environment. In GitHub Actions, environments can be configured with required reviewers who must explicitly approve a deployment, wait timers that introduce a deliberate delay between approval and execution, branch restrictions that limit which branches can trigger deployments to sensitive targets, and custom deployment protection rules via GitHub Apps for advanced validation logic. Note that GitHub environment protection features are plan-dependent: public repositories can use them on any plan, but required reviewers, wait timers, and related deployment protection rules for private or internal repositories require GitHub Enterprise Cloud. Validate plan availability before assuming parity with Azure DevOps approvals and checks.
In Azure DevOps YAML pipelines, protect environments and other resources with approvals and checks that are defined on the environment or resource itself, not in the pipeline YAML.
Common checks include manual approvals, branch control, business hours, evaluate artifact, query Azure Monitor alerts, invoke REST API, invoke Azure Function, required template, and exclusive lock.
This separation of duties matters because resource owners govern deployment policy independently of pipeline authors. Classic release gates such as work item queries should be treated separately from YAML environment checks.
Without environment protection rules, any pipeline run that reaches a deployment stage can execute without an independent checkpoint. A compromised pipeline, a misconfigured branch policy, or a malicious pull request that injects code into a trusted branch can then deploy directly to production. Protection rules create a human-in-the-loop checkpoint that breaks this attack chain, ensuring that an authorized reviewer validates the deployment before it proceeds.
This task supports Verify explicitly by requiring that every deployment to a protected environment is approved by a designated identity, constrained to authorized branches, and evaluated against deployment health signals before execution. It also reinforces Use least privilege access by restricting which workflows and branches are permitted to target production environments.