How to Setup Branch Protection Rules in Azure DevOps

Overview of Azure DevOps Branch Policies

Branch protection rules are a crucial part of securing source control management systems. Azure DevOps branch policies enable administrators to add tests that new code, in feature branches, must pass prior to being merged into the master branch. In my previous post, I covered how to add branch protection rules in Github, Gitlab and Bitbucket. This post will discuss Azure DevOps branch protection policies.

Getting Started

In order to reach the Azure DevOps branch policies from the repository overview screen, click on Branches in the side panel:

Choose the branch you wish to protect, click on the 3 dots and open Branch policies:

Let’s deep dive into the suggested settings:

Require a minimum number of reviewers

We would recommend requiring at least one reviewer on pull requests. This simple act helps protect the production branch in two key ways:

1. It gives reviewers the chance to find mistakes in code
2. It gives reviewers the chance to spot potentially suspicious anomalies such as a longtime developer committing to repo for the first time

Requestors should not be allowed to approve their own changes, and completion of the merge should be blocked when reviewers vote to wait or reject the changes. In case new changes are pushed, at least one approval should be made on the last iteration. We also strongly recommend restricting the “git force push” capability, which could serve as a workaround to this rule.

Check for comment resolution

Limit merge types

We would recommend limiting the allowed merge types to squash merge only. This option condenses the multiple commits from the side branch into a single commit in the main branch. It is far easier to track changes and isolate issues when a feature is contained in a single commit, rather than spread across multiple ones. You may read more about this strategy here: https://learn.microsoft.com/en-us/azure/devops/repos/git/merging-with-squash?view=azure-devops

Build Validation

It is crucial to make sure that the changes that were introduced in the side branches are verified as safe and operational before the new code is added to the main branch. This is done by creating a build policy that relies on your Azure DevOps pipelines. 

One potential downside to build validation, in an age of cloud computing, are the compute costs. We think these costs are worth the benefit. However, one way to minimize the cost is to trigger the build validation manually. By doing so, you may avoid executing the pipeline on intermediate commits within the pull request.

You should consider having the build expire when the main branch is updated; the changes in the pull request should be executed against the latest code to avoid collisions or unexpected behaviors.

Status Checks

It is recommended to enable status checks that automatically verify the code quality. For example two status checks that Cycode offers are:

• Detecting hardcoded secrets: Validates the existence of passwords and other sensitive information that may have been added accidentally
• Infrastructure-as-Code scanning: Checks cloud configuration files against best practices to suggest critical security improvements

Automatically Included Reviewers

If you wish to have some code reviewed by a specific team leader or tech lead, you can assign them to be made reviewers automatically according to the relevant folder within Azure repos.

You can use wildcard in the folders field (for example, *.tf to make sure a team leader reviews the Terraform configuration changes), or leave the field empty to have a specific person become a reviewer for each complete pull request in this repository.

How Cycode Can Help

Cycode secures DevOps pipelines and provides full visibility into enterprise development infrastructure. Powered by its knowledge graph, Cycode’s advanced detection capabilities correlate event data and user activity across the SDLC to create contextual insights and automate remediation. Cycode delivers security, governance and pipeline integrity without disrupting developers’ velocity. Cycode solve the following use cases:

• Centralizing governance and security policies across the SDLC
• Reducing code tampering risks 
• Preventing hardcoded secrets
• Detecting source code leakage
• Securing infrastructure-as-code

To determine if Cycode can help your organization, please start a 14 Day Free Trial or request a demo.