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.

Thanks!

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. 

David.

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

Hi,
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?

Thanks,
Ramo

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.