GitHub Branch Protection Checklist
Branch protection is what stands between a stolen credential and your release branch. Work through the controls that decide whether a bypass is possible — require a PR and reviews, required status checks, restrict who can push, block force-push, disallow admin bypass, require signed commits and restrict the workflow source — and get a weighted score, the prioritised gaps and an export. Controls tagged LiteLLM each break a link in the October 2026 LiteLLM-style bypass. Nothing is uploaded.
Mark each protection as enforced, partial or not set on your default and release branches. Controls tagged LiteLLM each break a link in the October 2026 LiteLLM-style bypass chain. Scored in your browser — no repository is read and nothing is uploaded.
Review gates
Make a change pass through other humans before it reaches a protected branch.
- Require a pull request before mergingLiteLLMcritical
Direct pushes to the protected branch are blocked; every change arrives as a reviewable PR.
- Require at least 2 approving reviewsLiteLLMhigh
A single compromised or careless approver cannot merge alone. Two independent approvals raise the bar for a malicious change.
- Dismiss stale approvals on new commitshigh
An approval given for one diff should not carry over to code pushed after it. Otherwise an attacker gets approval, then amends the PR.
- Require review from Code OwnersLiteLLMhigh
Sensitive paths (release scripts, .github/workflows, CI config) must be approved by their owners, not just anyone.
- Require conversation resolution before merginglow
Unresolved review comments cannot be silently bypassed on the way to merge.
Integrity & signing
Prove what is on the branch is what reviewers approved, from whom they think.
- Require status checks to pass (and branch up to date)high
CI, tests and security scans must pass on the exact merged state before merge. "Require branches to be up to date" closes the stale-base gap.
- Require signed commitsmedium
Every commit on the branch must carry a verified signature, so an attacker cannot forge authorship or inject unsigned commits.
- Require linear historylow
Blocks merge commits that can obscure what actually landed, making the history auditable.
Push restrictions & bypass
Control who can write to the branch — and ensure nobody can quietly step around the rules.
- Block force pushes to protected branchesLiteLLMcritical
Force-push is how a cover-up rewrites history. Blocking it means the record of what happened cannot be overwritten.
- Restrict who can push to matching branchesLiteLLMhigh
Only an explicit allowlist of people/teams/apps can push or merge. Narrows the set of identities whose compromise matters.
- Do not allow administrators / bypass actors to bypassLiteLLMcritical
If owners and admins can bypass protections, a single compromised admin credential voids every rule above. This is the exact LiteLLM-style failure.
- Restrict branch deletionmedium
Protected branches cannot be deleted out from under you.
Workflow & ruleset controls
Protect the pipeline itself, and put the rules where a repo admin cannot quietly edit them.
- Enforce protections via an organisation ruleset, not per-repo settingsLiteLLMhigh
Org-level rulesets are managed centrally; a compromised repo admin cannot weaken them the way they can edit a single repo's branch settings.
- Restrict which Actions/workflows can run (trusted source only)LiteLLMhigh
Limit Actions to those from your org or an explicit allowlist, and require approval for workflows on fork PRs — stops a poisoned or fork-sourced workflow running with secrets.
- Protect .github/workflows via CODEOWNERS + reviewmedium
Changes to CI definitions are the highest-leverage edits in the repo and must get owner review like any release code.
Prioritised gaps (15)
- 1.criticalLiteLLMNot assessed
Require a pull request before merging
Fix: Enable "Require a pull request before merging" on the default and release branches.
- 2.criticalLiteLLMNot assessed
Block force pushes to protected branches
Fix: Disable "Allow force pushes" on protected branches (it is off by default — keep it off, including for admins).
- 3.criticalLiteLLMNot assessed
Do not allow administrators / bypass actors to bypass
Fix: Enable "Do not allow bypassing the above settings" / include administrators; keep the ruleset bypass list empty or tightly scoped.
- 4.highLiteLLMNot assessed
Require at least 2 approving reviews
Fix: Set required approvals to 2 (or more) in the branch rule / ruleset.
- 5.highNot assessed
Dismiss stale approvals on new commits
Fix: Enable "Dismiss stale pull request approvals when new commits are pushed".
- 6.highLiteLLMNot assessed
Require review from Code Owners
Fix: Add a CODEOWNERS file and enable "Require review from Code Owners", covering /.github and release tooling.
- 7.highNot assessed
Require status checks to pass (and branch up to date)
Fix: Enable required status checks for your CI/security jobs and "Require branches to be up to date before merging".
- 8.highLiteLLMNot assessed
Restrict who can push to matching branches
Fix: Enable "Restrict who can push to matching branches" and keep the allowlist minimal.
- 9.highLiteLLMNot assessed
Enforce protections via an organisation ruleset, not per-repo settings
Fix: Define the protections as an organisation ruleset targeting default/release branches across repos, managed by org owners only.
- 10.highLiteLLMNot assessed
Restrict which Actions/workflows can run (trusted source only)
Fix: In Actions settings, allow only selected/verified actions, require approval for first-time contributors, and gate fork-PR workflows.
Scored entirely in your browser — no repository is read and nothing is uploaded. Control themes follow GitHub's protected-branches and rulesets documentation. Educational — not affiliated with GitHub.
What this checklist is
- An interactive checklist of the GitHub branch-protection and ruleset controls that decide whether a single compromised credential can push, merge and cover its tracks on your default and release branches.
- Fifteen controls across four areas — review gates, integrity & signing, push restrictions & bypass, and workflow/ruleset controls — each with a severity, a plain-English rationale and a concrete fix.
- Controls that would have broken a link in the October 2026 LiteLLM-style bypass chain are tagged "LiteLLM": require a PR + reviews, block force-push, restrict who can push, disallow admin/bypass, restrict workflow source, and manage protections as an org ruleset.
- Mark each Enforced / Partial / Not set to get a weighted 0–100 coverage score, a per-area breakdown, prioritised gaps and a copyable / downloadable report.
- 100% client-side — no repository is read, nothing is uploaded. Control themes follow GitHub's own protected-branches and rulesets documentation.
Why this matters
In the October 2026 LiteLLM GitHub-identity supply-chain compromise, as publicly reported, the damage was done not by defeating a protection but by holding a credential that could step around them. With org-owner reach, the attacker exfiltrated CI secrets, shipped a release built from a fork source, deleted run records and force-pushed to cover up.
Every one of those steps has a branch or ruleset control that would have gotten in the way: required reviews and restricted push mean a stolen token cannot merge alone; a blocked force-push means history cannot be overwritten; a trusted-workflow-source policy means a fork-built release does not run; and an org-managed ruleset with no admin bypass means a single compromised admin cannot quietly switch the rules off. The uncomfortable truth the incident underlines is that protections which administrators can bypass are not protections — so the highest-value settings here are the ones that apply to everyone, enforced centrally. This is an educational self-assessment referencing a real, reported incident for context; PlayCISO is not affiliated with LiteLLM or GitHub.
Frequently asked questions
What single setting most often voids all the others?
Allowing administrators (or a ruleset "bypass" actor) to skip the protections. If owners and admins can bypass the rules, then every review gate, force-push block and push restriction is optional the moment one admin credential is compromised. GitHub lets you enable "Do not allow bypassing the above settings" / include administrators, and keep the ruleset bypass list empty — that is the control that makes the rest real. It is tagged LiteLLM in the checklist for exactly this reason.
Why block force pushes specifically?
A force push rewrites history. In a supply-chain cover-up, force-push is how an attacker makes the malicious commit look like it was never there, or replaces the record of what happened. Blocking force pushes on protected branches (the default, which you should keep — including for admins) means the history of what landed cannot be quietly overwritten.
Branch protection rules or rulesets — which should I use?
Rulesets, managed at the organisation level, are the stronger choice. A classic per-repo branch protection rule can be edited by anyone with admin on that repo, so a compromised repo admin can simply weaken it. An organisation ruleset is managed by org owners and applied across repositories, so a single repo admin cannot quietly loosen it. Define your protections as an org ruleset where you can.
How does this connect to the LiteLLM incident?
In the October 2026 LiteLLM compromise, as publicly reported, an attacker with an org-owner token was able to exfiltrate CI secrets, publish a release built from a fork source, delete run records and force-push to cover up. Strong branch and ruleset protections — required reviews, restricted push, no admin bypass, blocked force-push, trusted workflow sources, and org-managed rulesets — are precisely the controls that turn "owner token" into "still blocked by the rules" rather than "game over". This tool references a real, reported incident for context and is not affiliated with LiteLLM or GitHub.
Is a high score proof my branches are safe?
No. This scores the controls you say you enforce; it reads nothing and verifies nothing. It is a structured self-assessment to find gaps, not an audit. Confirm each setting in GitHub itself, and re-check after any change.
This tool is free and always will be. Would a Pro workspace — saved designs, team sharing and exports — be worth paying for?
Show me Pro →No account needed to use this tool — this just tells us whether Pro is worth building out.