Pushing to a protected branch with required status checks


The protected branch UI says this under “Restrict who can push to this branch”:

Specify people or teams allowed to push to this branch. Required status checks will still prevent these people from merging if the checks fail.

But I can’t find anything that tells me *how* to run a status check when doing a push into a branch. Can someone explain how to do this? Situation:

  • We have repos in which teams have write access so they can push directly to their own branches.
  • Our policies require that they issue pull requests to merge changes from those branches into our master branch.
  • We have status checks on the master branch that run when PRs are created to run validation and other checks.
  • The status checks are currently not required but we want to make them required so that team members are forced to address issues that are found.
  • We have a background process that needs to push directly into the master branch. 

When we make status checks required, this prevents the background process from pushing changes into the master branch. This makes sense but the red text above makes me think there’s a way to trigger the status checks when trying to push into master, but I can’t find any info about how to do it. So I’m wondering:

  • *How* do you get a status check to run on a commit or set of commits being pushed into a protected branch that has required checks?
  • If “include administrators” isn’t enabled, can admins bypass status checks?

thanks for any help you can give.


Hi @dstrome,

It sounds like you are already using status checks correctly in this way. Status checks are a way to prevent people from merging Pull Requests into a protected branch. Since you’re already requiring Pull Requests to merge into master, you shouldn’t have anyone directly pushing to that protected branch, so everyone will need to go through those status checks.

To answer your other question, yes, if you don’t check “include administrators”, they can bypass these requirements.


1 Like

hey @that-pat, thanks for the reply.

I guess what’s confusing me is the wording of the string “Required status checks will still prevent these people from merging if the checks fail”. To me that implies that the status checks can be kicked off when a push into the branch is done. Either that or there’s another circumstance where the checks have already run somehow. 


1 Like

Hi @dstrome,

GitHub doesn’t kick off any status checks, but it will not allow the merge to happen unless there have been success reports from all required checks. The way that is usually set up is that people set up web hooks to fire off ci jobs when pushes come in, and those CI jobs do status reporting.

1 Like

Thanks @seveas, that makes sense. Thanks for the reply.

I am wondering still this status check can be bypassed by a person with repo write access by calling the GitHub API to set the required status context. Thoughts?


1 Like

Anyone with the appropriate permission can use the status api if you would like to protect against a single attacker bypassing with compromised credentials you are going to need to take a layered approach. If it’s an Adminstrator level account, its game over. We can slow them down and alert on things to notify response teams.

My reccomended settings for mitigation:

  • Require Pull requests reviews before merging: as your own reviews don’t count this turns a pull request into a n+1 key system unless they are an admin. 
  • Require review from Code Owners: this takes it from 2 keys of anyone with access to a smaller group of people who are owning that product, sme, compliance signoffs, etc. Some orgs encourage teams to cross boundries and therefore want tthem to have write acess while allowing small teams to remain in control.
  • Require Status Checks to pass: obviously its important to enable this for some but not others, it in theory can be bypassed but this would be an auditable event.
  • Require Signed commits: if an attacker could comprise your github password or private ssh key through a leak or exfiltration there is no guarantee that they have your private PGP key.
  • Include Adminstrators: I honestly reccomend always setting this. An admin can always turn off, do a terrible thing, and turn it back on. This IMO is a meaningful protection against accidetally destructive actions by an admin.
  • Restrict who can push to matching branches: This is important in a different sense than the others and I reccomend it when you have projects where merge order is critical.

At the end of the day stopping a rougue or compromised admin is effectively impossible but we can ensure that we prevent this from happening with non admin users and auditability when protections are bypassed. I know its a hard thing to balance in larger organizations but its absolutely critical. I decided to use terraform and github itself expose api internals to reduce the number of opperations that required a user to directly perform operations. Doing so allowed us to remove a lot of admins, while not every operation is accessible through the api and the terraform providers may not always support everything the api does (yet) I would highly encourage this approach. This shifted a lot of requests from operations (and security) teams back to the engineers that were requesting the change in the first place.