All Collections
Control Tests
Test: Formal Code Review Process
Test: Formal Code Review Process

Drata reads branch configurations for all in-scope repos in your version control system to ensure reviews are required before merging code .

Ashley Hyman avatar
Written by Ashley Hyman
Updated over a week ago

BEFORE DIVING IN

Please note that inherited permissions are not supported at this time, thus items such as inherited branch restrictions, can not be retrieved by Drata.

ASSOCIATED DRATA CONTROL

This test is part of the Code Review Process control that ensures all application code changes, reviews, and tests are performed by someone other than the person who made the initial code change.

WHAT TO DO IF A TEST FAILS

If Drata finds that branch configurations allow code changes merged by the same user into the main branch of your version control system, without any other user interaction, the test will fail. With a failed test you will receive a notification from Drata stating that there are code repositories that allow code changes to be merged into the main branch without being reviewed by another team member.

To remediate a failed test, you will need to make sure that a code reviewer is assigned to each merge request, and that reviews cannot be bypassed. It is also recommended to enable a policy on the main branch that requires reviews on all merge requests.

STEPS TO REMEDIATE

To ensure a validated state when testing for the formal code review process, please follow the steps listed in the table below. Once the provider steps have been completed, navigate back to Drata and execute the test.

Provider

Provider Steps

AWS CodeCommit

As the Admin:

  1. Go to Source -> Approval Rule Templates

  2. Click 'Create Template'

  3. Ensure a value of at least 2 is provided for 'Number of approvals needed'

  4. Select one or more repositories to which to apply this template under 'Associated repositories'

  5. Ensure these repositories have a default branch (check under Source -> Repositories -> click on a repo name -> Branches)

Azure DevOps Repos

Branch Policies on the default branch must include at least one reviewer, and the checkbox for "Allow requestors to approve their own changes" is off.

OR

Branch Policies on the default branch includes at least two reviewers.

Bitbucket

Both branch match kinds are supported. If you're setting up branch protection by name (i.e. you selected the option "By name or pattern" at the top of your branch permissions):

  • then you must enter the same branch name you have specified as the default branch in the Repository settings screen -> Advanced dropdown -> Main branch dropdown

In contrast, if you're setting up branch protection by type (i.e. you selected the option "By Type"):

  • then you must select the "Production" branch type

Then, apply the following two settings:

  1. Check the box for "Prevent a merge with unresolved merge checks" at the very bottom of the Branch permissions settings

    1. NOTE: the use of this checkbox requires you to be on the Bitbucket Premium plan

  2. Check either of the "Check for at least X approval" and "Check for at least X approval from default reviewers" checkboxes

    1. Either checkbox is fine, and you need a value of at least 1 for whichever one you decide to use.

GitHub

As the owner:

  1. Go to the connected Organization

  2. Go to each repo under Repositories

  3. Click on the Settings tab

  4. In the left menu click on Branches

  5. Next to Branch protection rules - click Add rule

  6. Enter your Default Branch name pattern, e.g. Main or Production

  7. Select checkbox for "Require a pull request before merging" - refer to step 6 for more details

  8. (Optional) We recommended leaving the Allow force pushes checkbox unchecked, but depending on your preferences, you can select that checkbox under "Rules applied to everyone including administrators" - refer to step 16 for more details.

    1. Selecting this option might create more cases where a single user bypasses other rules to push their code to production.

  9. Click the Create button

GitLab

NOTE: Repos on the (legacy) GitLab Bronze plan cannot pass this test. Accounts must be on at least the (legacy) Silver or Premium tier.

As the owner, go to one of the connected projects. Choose to either set merge request rules at the project level, or define protected branch rules at the repository level.

Project merge requests

  1. Click on the Settings tab in the left sidebar

  2. Click General

  3. Expand Merge requests (note this is a GitLab Premium feature)

  4. Add a value of at least 1 for "Approvals required" for an existing rule, or add your own custom approval rule.

  5. Check the box for "Prevent editing approval rules in merge requests"

Repository protected branches

  1. The default branch for the project is a protected branch. Protected branches are available to Pro, Team, and Enterprise plans.

  2. Click on the Settings tab in the left sidebar

  3. Click on the Repository tab

  4. Expand Protected branches

  5. Verify the default branch is listed under protected branches. If the default branch is not listed under protected branches, add a rule for it.

NOTE: If one of your repos shows an error message of "Request failed with status code 404" in the raw test evidence, this means no protected branches have been defined for this repo. You should define at least one according to the instructions above and rerun the test.

HELPFUL RESOURCES

Did this answer your question?