A five person team needs a small set of rules on the main branch: require pull requests with at least one approval, require passing status checks, block force pushes and deletions, require review from code owners for sensitive paths, and do not allow bypassing. These turn your CI pipeline from a suggestion into a control.
Why branch rules are pipeline security
Your pipeline runs whatever the main branch says. If one compromised laptop or one rushed push can change the workflow file, every secret in that pipeline is exposed. Branch rules put a second person and a passing build between a change and production.
GitHub's documentation lists the options in a protection rule: require pull request reviews, require status checks, require conversation resolution, require signed commits, require linear history, require merge queue, require deployments to succeed, lock branch, do not allow bypassing, restrict who can push, and control force pushes and deletions. By default, a rule disables force pushes and deletions on matching branches.
The starter set
| Rule | Why it matters for CI |
|---|---|
| Require a pull request with 1 approval | A second pair of eyes on workflow and dependency changes |
| Require status checks to pass | The tests and scans must run and succeed before merge |
| Block force pushes and deletions | History and audit trail stay intact |
| Require review from code owners | Sensitive paths get an informed reviewer |
| Do not allow bypassing | Admins follow the same path |
Two practical points from the docs. Job names used as required checks should be unique across workflows, because duplicate names create ambiguous results that can block merges. And approval from any one listed code owner satisfies the code owner requirement, so list a team, not one person.
Protect the workflow files themselves
Add a CODEOWNERS file and give your most careful reviewer or a small team ownership of the .github/workflows directory. GitHub's docs also say to define an owner for the CODEOWNERS file itself, and that the most secure method is to place it in the .github directory with the repository owner on that directory.
For GitLab teams the same idea applies with protected branches. GitLab can limit a CI/CD variable to pipelines on protected branches and tags, so credentials stay out of reach of unreviewed branches. See our post on protected variables in GitLab CI.
Rulesets or classic rules?
GitHub's docs describe rulesets as an alternative with advantages: multiple rulesets can layer on one branch, you can switch a ruleset's enforcement without deleting it, and anyone with read access can view active rulesets, which helps auditors. Either works. Pick one and be consistent. Feature availability varies by plan, so check the current docs for private repositories.
What not to do
- Do not require so many approvals that people route around the rule.
- Do not give a bot account permission to bypass without watching what it does.
- Do not let CI auto approve its own pull requests. GitHub has a setting to prevent workflows from creating or approving pull requests, and the docs call out the risk.
Try it yourself
The demo shows how a policy gate can stop a pull request before merge. Click a failing check and look at what the reviewer sees.
Click through it at your own pace, or open it full screen.
Quick check
Are branch rules enough to secure CI?
No. They control what reaches main. You still need token scoping, pinned actions and careful secrets.
Can admins bypass the rules?
Often yes by default. Turn off bypass so the rules apply to everyone, and keep an audited break glass path.
Sources
- About protected branches, GitHub Docs
- About code owners, GitHub Docs
- About rulesets, GitHub Docs
- Secure use reference, GitHub Docs
Last reviewed: 19 October 2026.
