Ask the partner for a screenshot or export of the protection rules on its main and release branches, plus a sample of recent merged changes. You want required reviews, required status checks, blocked force pushes and limited bypass rights. Together they show that no single person can alter shipped code unseen.
What the rules can enforce
GitHub's documentation on protected branches lists what a rule can require. Merges can require a set number of approving reviews, from people with write access or from designated code owners, and approvals can be dismissed as stale when new commits change the diff. Status checks can be required to pass before merging. Signed commits can be required. Force pushes are blocked by default on protected branches. Other options include resolved conversations, linear history, a merge queue, branch locking and restrictions on who can push.
Other code hosts have similar controls under different names. Ask for the equivalent.
Evidence worth asking for
- Rule export for each critical repository. Not just one showcase repo.
- A list of who can bypass. Administrators who can skip review are an exception you should know about.
- Ten recent merged changes to the main branch. Check that each shows a reviewer who is not the author and passing checks.
- CODEOWNERS file. It shows whether sensitive paths have named reviewers.
- Emergency change procedure. How does a hotfix get merged at 2 a.m., and who reviews it afterwards?
What each control tells you
| Control | What it proves | What it does not prove |
|---|---|---|
| Required review | A second person looked | That they understood the change |
| Required checks | Tests and scans ran | That the checks are meaningful |
| Blocked force push | History cannot be silently rewritten | That secrets were never committed |
| Signed commits | Commits tie to a key | That the key holder is trusted |
Rules matter less than their exceptions. A rule with five administrators who can bypass it is weaker than it looks.
Common gaps
- Protection on the main branch but not on release branches, which are what actually ship.
- Build and deployment workflow files that any contributor can edit, so a pull request can change the checks that gate it.
- Shared service accounts that approve their own pull requests.
- Infrastructure code held to a lower standard than application code.
Try it yourself
Open the demo and see how a pull request gate blocks a change that fails a policy. Look at which checks decide the outcome.
Click through it at your own pace, or open it full screen.
Safeguard's policies, gates and guardrails can enforce checks on pull requests, and you can run a free scan to see what a gate would flag in your own code.
Quick check
Is one required reviewer enough?
It is a reasonable floor for most code. Raise it for security sensitive paths, and look at who the reviewers are.
Does branch protection stop a malicious insider?
It raises the effort and leaves a trail. It does not stop collusion or a compromised administrator account.
Sources
Last reviewed: 19 October 2026.
