CICD-SEC-1 Insufficient Flow Control Mechanisms Guide

If one compromised account, human or bot, can get code or an artifact from a commit to production without anyone else agreeing, the pipeline has no flow control. CICD-SEC-1 Insufficient Flow Control Mechanisms is the first risk in the OWASP Top 10 CI/CD Security Risks, and it is the reason a stolen developer token so often becomes a production incident. This guide explains what OWASP means by flow control, the specific settings in GitHub and GitLab that implement it, where bots and service accounts break the two-person rule, and how to evidence the controls to an auditor. It builds on the Top 10 CI/CD Security Risks and the CI/CD Security Guide, and is written for platform engineers, DevSecOps teams and the security architects who own release governance.

Key takeaways

No single identity should ship alone. OWASP's core recommendation is that no human or programmatic entity can push sensitive code or artifacts through the pipeline without external verification or validation.
Defaults leave gaps. On GitHub, administrators bypass branch protection unless "Do not allow bypassing the above settings" is enabled, and "Allow administrators to bypass configured protection rules" is selected by default on deployment environments.
Bots are reviewers too. Auto-merge rules, dependency bots and workflows that can approve pull requests are the most common way unreviewed code reaches a protected branch.
Protect the artifact path, not only the source. Artifacts should flow onward only if a pre-approved CI service account built them, and production should be checked for drift from its CI/CD origin.
Separate the right to push from the right to deploy. Any account allowed to push unreviewed code must not also be able to trigger the deployment pipeline for that repository.

What it is and who it applies to

OWASP defines the risk as "the ability of an attacker that has obtained permissions to a system within the CI/CD process (SCM, CI, Artifact repository, etc.) to single handedly push malicious code or artifacts down the pipeline, due to a lack in mechanisms that enforce additional approval or review." The official name, "CICD-SEC-1: Insufficient Flow Control Mechanisms", matches this guide's title.

The key word is single-handedly. CICD-SEC-1 assumes the attacker already holds some access (a phished developer, a leaked personal access token, a compromised bot) and asks whether the pipeline forces a second, independent party to agree before the change reaches production. OWASP lists seven abuse paths:

Abuse path (OWASP)	Typical root cause	Primary control
Push to a branch that deploys automatically	Unprotected deployment branch	Branch protection with required review
Push to a branch, then trigger a production pipeline manually	Pipeline trigger rights not tied to review	Environment approvals, deployment branch restrictions
Push directly to a utility library used in production	Shared libraries outside the review regime	Same protection on every repository that reaches production
Abuse an auto-merge rule	Bot merges based on spoofable criteria	Restrict and review auto-merge logic
Abuse branch protection exclusions	Bypass lists, excluded users or branches	No exclusions; audited break-glass only
Upload an artifact posing as a build output	Registry accepts uploads from any account	Only CI service account artifacts promoted
Change production directly (for example an AWS Lambda function)	Console or API write access in production	Remove direct write, detect drift

It applies to any organisation that deploys through a source control system and CI/CD platform, whether GitHub, GitLab, Bitbucket, Azure DevOps or Jenkins, and to open source maintainers whose packages flow into other people's pipelines. The concrete settings below use GitHub and GitLab because their documentation names them precisely; the same principles apply elsewhere.

Structure and key requirements

OWASP gives five recommendations. Each one becomes a set of platform settings.

1. Branch protection without exclusions

Protect every branch whose code reaches production or another sensitive system. These GitHub branch protection settings matter most for CICD-SEC-1:

GitHub setting	Flow control value	Recommendation for production branches
Require pull request reviews before merging	Enforces a second person	On, at least one approval, two for high-risk repositories
Dismiss stale pull request approvals when new commits are pushed	Stops "approve then add a commit"	On
Require review from code owners	Routes sensitive paths (workflows, IaC) to owners	On, with workflow and deployment files owned by the platform team
Require approval of the most recent reviewable push	The last pusher cannot be the only approver	On
Require status checks before merging	Tests and scans must pass	On, strict for release branches
Require signed commits	Ties commits to a verified key	On where developer key management is mature
Require deployments to succeed before merging	Staging gate before merge	Where a staging environment exists
Do not allow bypassing the above settings	Applies rules to administrators	On; without it admins and roles with "bypass branch protections" skip every rule
Restrict who can push to matching branches	Limits direct pushes	On, nobody except the merge process
Allow force pushes / Allow deletions	History rewrite and removal	Off

GitHub rulesets add layering: several rulesets and a branch protection rule can target the same branch, and the most restrictive version of each rule applies. Rulesets can be set at organisation level on supported plans, carry an explicit bypass list (roles, teams or GitHub Apps) and can be switched between Active and Disabled without deletion, which makes them the better tool for enforcing one baseline across many repositories.

In GitLab (Premium and Ultimate), the equivalent merge request approval settings are "Prevent approval by merge request creator", "Prevent approvals by users who add commits", "Prevent editing approval rules in merge requests", "Require user re-authentication (password or SAML) to approve" and "Remove all approvals when commits are added to the source branch".

2. Auto-merge kept narrow

OWASP asks teams to limit auto-merge rules to the minimum contexts, review their code so they cannot be bypassed, and avoid importing third-party code into the auto-merge process. Homebrew's 2021 disclosure is the reference case: a GitHub Action approved pull requests that only changed a cask's version, another Action then merged them, and the diff parser it relied on could be spoofed into ignoring malicious lines. Homebrew removed both Actions, removed its bots' ability to commit to the cask repositories and required maintainer review for every cask pull request.

On GitHub, also leave "Allow GitHub Actions to create and approve pull requests" unchecked, so a workflow's GITHUB_TOKEN cannot satisfy the review requirement, and use the restricted workflow permissions setting (read access to contents and packages) by default.

3. Approval before production pipelines run

GitHub deployment environments implement this. Configure required reviewers (up to six people or teams, one approval needed), enable "Prevent self-review" so the person who triggered the run cannot approve it, restrict deployment branches and tags to protected refs, add a wait timer if you need a cancellation window, and deselect "Allow administrators to bypass configured protection rules". Environment secrets become available to a job only after its rules pass, so production credentials stay out of reach of unreviewed runs. Availability of reviewers and wait timers for private repositories depends on the GitHub plan.

4. Artifacts only from the approved builder

Promote artifacts to staging and production only if they were created by a pre-approved CI service account. In practice that means separate write identities for the registry (only the CI build identity can publish to the release repository), signed artifacts with provenance, and a deployment step that verifies signature and provenance before release. See the OWASP CI/CD Top 10 CICD-SEC-9 Improper Artifact Integrity Validation Guide.

5. Drift detection

Detect differences between what runs in production and what the pipeline produced, and correct any drifted resource. The Codecov Breach 2021 shows the value: an attacker modified the Bash Uploader script in cloud storage outside the release process, and it ran in customers' CI jobs for about two months until one customer compared it with the published checksum.

Choosing the level of control

Situation	Minimum flow control	Trade-off
Small team, two or three engineers	One required approval, no admin bypass, environment approval for production	Approvals can feel ceremonial; keep them because a stolen token is the threat, not a colleague
Large organisation, many repositories	Organisation-level rulesets, code owners on workflow files, environment approvals with Prevent self-review	Central baselines reduce per-team flexibility; offer an exception process
Regulated release (payments, health, critical infrastructure)	Two approvals, signed commits, separate deploy approvers, provenance verification	Slower releases; use merge queues and pre-approved change types to recover speed
Open source project	Maintainer review for every merge, no bot commit rights, fork workflow approval	Contributor friction; automate checks, not approvals

Identity and NHI requirements

Flow control is an identity problem: every gate is only as strong as the separation between the identities on each side of it. SLSA's Source Level 4 states it directly: changes to protected branches need review and agreement from two trusted persons, approval applies to the final revision, and a trusted robot (it gives Dependabot as an example) may hold a standing exception only by explicit decision. The NSA and CISA guidance on CI/CD environments likewise calls for two-person rules for all code updates and for separating code committers from those who control the build environment.

Bots: dependency bots, merge bots and GitHub Apps should propose, never approve and merge alone. The axios npm Compromise 2026 shows why: GitGuardian found that 50 of the pull requests it could examine that pulled in the backdoored version were merged by a bot with no human interaction.
Bypass lists: every entry in a ruleset bypass list, every admin and every custom role with "bypass branch protections" is a non-reviewed path. Keep the list empty except for a break-glass identity with alerting.
Personal access tokens: a token issued to a developer carries their push rights; if it leaks it acts as them. Prefer fine-grained, short-lived tokens and OIDC federation for pipelines. See the OWASP CI/CD Top 10 CICD-SEC-2 Inadequate Identity and Access Management Guide.
Shared accounts: commits pushed as a shared or impersonated account defeat review attribution. The 2021 PHP incident involved two malicious commits pushed to the php-src repository under the names of two core maintainers, using password authentication over HTTPS on the project's own git server; the project then moved its primary repositories to GitHub.
CI service accounts: the build identity that publishes artifacts must not be usable by humans and must not have rights to approve its own deployments. See the CI/CD Pipeline Identity Security Guide.

Implementation steps

Map the paths to production. For each production system, list the repositories, branches, pipelines, artifact repositories and direct-access routes (console, API, kubectl) that can change it, including shared libraries. This is the scope of CICD-SEC-1.
Measure current state before enforcing. Export branch protection and ruleset settings, bypass lists, environment rules and auto-merge configurations across all repositories. Report which production paths have no second party.
Apply an organisation baseline. Create an organisation ruleset requiring pull request review, dismissal of stale approvals, approval of the most recent push, status checks and no force pushes for default and release branches. Pilot it on a small set of repositories, then widen.
Close the bypasses. Enable "Do not allow bypassing the above settings", empty bypass lists except one break-glass identity, uncheck "Allow GitHub Actions to create and approve pull requests", and add CODEOWNERS for workflow and deployment files.
Gate deployments. Move production credentials into environment secrets, add required reviewers with Prevent self-review, restrict deployment branches and remove administrator bypass.
Restrict artifact promotion. Allow only the CI build identity to publish release artifacts, sign them, and verify signature and provenance at deploy time.
Remove direct production write. Replace standing console and API write access with just-in-time elevation and add drift detection that alerts on, and reverts, out-of-pipeline changes.
Plan rollback and exceptions. Rulesets can be set to Disabled without deletion if a rollout blocks a critical fix; record every such change and every break-glass use, and review them within one working day.

Evidence and assessment

Auditors and internal assessors should be able to answer one question for any production change: who other than the author approved it, and could anyone have skipped that approval?

Control	Evidence	How to test
Branch protection on production branches	Exported ruleset and branch protection configuration per repository	Attempt a direct push and a self-approved merge with a test account
No admin or bypass path	Bypass lists, admin enforcement flag, list of roles with bypass permission	Attempt a merge as an admin test account without review
Bots cannot approve	Workflow permission settings, bot role assignments	Run a workflow that tries to approve a pull request
Deployment approvals	Environment rules, deployment history with approver identity	Trigger a production deployment from an unprotected branch
Artifact provenance	Signature and provenance verification logs at deploy	Push a manually built artifact to the registry and try to deploy it
Drift detection	Drift reports and remediation tickets	Make a controlled out-of-band change in a test environment

Detection and metrics

Monitor configuration changes: alert on any change to branch protection, rulesets, bypass lists, CODEOWNERS and workflow permission settings, and on GitHub environment events such as environment.update_protection_rule and environment.remove_protection_rule.
Monitor outcomes: merges to protected branches with zero human approvals, deployments approved by the person who triggered them, and production changes with no matching pipeline run.
Metric, coverage: percentage of production-reaching repositories under the organisation baseline (target 100 per cent).
Metric, bypass rate: bypass and break-glass uses per month, each with a ticket.
Metric, unreviewed merges: merges to protected branches without an independent approval (target zero).
Metric, drift: production resources found drifted from their pipeline origin, and mean time to correct.

Feed these events to your SIEM; see the OWASP CI/CD Top 10 CICD-SEC-10 Insufficient Logging and Visibility Guide.

Mapping to other frameworks

Framework	Reference	Relevance to CICD-SEC-1
NIST SP 800-53 Rev. 5	CM-3, CM-3(2), CM-5, AC-5, SA-10, SI-7, CM-14	Change control and testing, access restrictions for change, separation of duties, developer configuration management, integrity, signed components
NIST CSF 2.0	PR.PS-06, PR.AA-05	Secure development practices; access permissions with least privilege and separation of duties
NIST SP 800-204D	Software supply chain security in CI/CD pipelines	Strategies for integrating supply chain controls into pipelines
SLSA v1.2 Source track	Source L3 (continuous technical controls), Source L4 (two-party review)	Enforced controls on protected branches and two-person review
NSA and CISA, Defending CI/CD Environments	Two-person rules, least privilege, audit logs	Government guidance for the same controls
ISO/IEC 27001:2022	Annex A 5.3, 8.4, 8.32	Segregation of duties, access to source code, change management
CIS Controls v8.1	Control 16 Application Software Security	Secure development process
MITRE ATT&CK	T1677 Poisoned Pipeline Execution, T1195.002 Compromise Software Supply Chain, T1213.003 Code Repositories	Techniques that flow controls constrain

Common pitfalls

Protecting main but not release or hotfix branches: attackers push to whichever branch the deployment pipeline accepts. Restrict deployment branches on the environment, not only protection on main.
Leaving admin bypass on: GitHub branch protection does not apply to admins by default, and environments allow administrators to bypass by default. A phished admin token then ships alone.
Counting the author's own second account or a bot as the reviewer: "Require approval of the most recent reviewable push", Prevent self-review and GitLab's "Prevent approvals by users who add commits" exist to close this.
Trusting auto-merge logic: rules that merge "version-only" or "dependency-only" changes are code, and as Homebrew showed, code that parses diffs can be fooled. Auto-merge of a malicious dependency release is the fast path seen in the axios case.
Ungated workflow changes: if workflow files are not owned by a protected CODEOWNERS entry, a reviewed-looking pull request can rewrite the gate itself. See the OWASP CI/CD Top 10 CICD-SEC-4 Poisoned Pipeline Execution Guide.
Registry as a side door: controls on source mean little if a developer credential can upload an image tagged like a release build that the deployment picks up.

Practitioner checklist

Inventory every repository, branch, pipeline, registry and direct route that can change production.
Apply an organisation-level ruleset with required review, stale approval dismissal and approval of the most recent push.
Enable "Do not allow bypassing the above settings" and keep bypass lists to one alerted break-glass identity.
Uncheck "Allow GitHub Actions to create and approve pull requests" and use restricted workflow permissions.
Put workflow, deployment and IaC files under CODEOWNERS owned by the platform team.
Gate production with environment reviewers, Prevent self-review, deployment branch rules and no admin bypass.
Allow only the CI build identity to publish release artifacts and verify provenance before deploy.
Remove standing production write access and run drift detection.
Alert on changes to protection rules, rulesets and environment rules, and on unreviewed merges.
Report coverage, bypass rate, unreviewed merges and drift monthly.

OWASP CI/CD Top 10 CICD-SEC-1 Insufficient Flow Control Mechanisms Guide: Approvals, Branch Protection and Flow Controls