github
Admins can require PR approvals to be from people who didn't contribute to the PR
Summary
Pull requests are an important way to keep repositories safe from untrusted code. Using a branch protection rule, admins can require pull requests and approving reviews before changes can be merged into a target branch. That setup is shown here:
But what if the threat is from someone reviewing the pull request? A bad actor with the right permissions could patch a pull request with malicious code and leave an approving review themselves. Their approval may be all that's needed to merge the code into a mainline branch where it can find its way into production.
Intended Outcome
A new branch protection setting will prevent users who push changes to a pull request from being able to approve that pull request (or have their existing approval count). That helps ensure that changes are reviewed by someone other than the person who made them. GitHub initially built this protection for itself to meet FedRAMP security requirements. Now that it's baked, we're making it available to customers. This is part of GitHub's overall effort to strengthen repository security.
How will it work?
To use the feature, create or edit a branch protection rule. While editing the rule's settings, it's a best practice to enable the top option, Require a pull request before merging, and choose a number of required approvals. Then, enable the new feature by selecting Ignore approving reviews from pull request contributors, shown below. Be sure to save the settings.
Tip: it can be frustrating for developers to contribute to a pull request and then discover that they can no longer approve it. To help avoid this, make everyone aware of the policy and ensure that enough people are available to meet the required number of approvals.
