Azure DevOps – 6 recommendations to help with securing your branches

Using Azure DevOps daily on a continuous basis but, have you thought about the security of your branches?

In this blog post, I will give 6 recommendations to help you with securing your Azure DevOps branches! There is quite a number of ways and configurations you can do in relation to the security; these 6 recommendations will get you started:-

1. Branch Permissions
2. Don’t let users merge into branch without review
3. Automatically include reviewers when creating a pull request
4. Working with Azure Boards? Enforce linking a work item as a requirement on pull requests
5. Build Validation
6. Lock a Branch

1. Branch Permissions

Right at the core of each branch is its branch permissions, have you ever reviewed them?

For each branch, setup permissions specific to the branch so you control who can read and or update the code in your branch. Permissions are granular and can be set on an individual user basis and/or user groups. There is also inherited considerations and override permissions in relation to repo permissions also, see further here.

Reviewing branch permissions:-

• Select Repos -> Branches and you will now see an overview of the available branches in the repo you are currently in.

• Select the branch you want to review its security permissions and Select … (to right of branch) -> Branch Security.

• You will now see an overview of users and groups that currently have permissions to the branch.

• Review these permissions and restrict accordingly.

2. Don’t let users merge into branch without review

A code review before a change can be merged into any specific branch is considered a best practice on any software development project. There is a branch policy that can be created to require a minimum number of reviewers to approve the change before it can be merged into the end branch.

Some recommendations when setting the number of reviewers:-

• Two reviewers are considered the optimal number based on research
• If there is considered to be quite a large amount of changes within the branch, do consider this when setting the branch policy who can review. Pull request reviews tend to work best when these responsibilities are shared throughout the team.

Configuring Require a minimum number of reviewers:-

• Select the branch you want to configure and select … (to right of branch) -> Branch Policies
• Review as below Require a minimum number of reviewers

3. Automatically include reviewers when creating a pull request

To supplement recommendation 2. Don’t let users merge into branch without review, you can also setup a branch policy to automatically include reviewers when creating a pull request.

In here, I do recommend adding a group rather than single user as you can then set a minimum number of reviewers within this policy also.

Configuring Automatically included reviewers:-

• Select the branch you want to configure and select … (to right of branch) -> Branch Policies
• Review as below Automatically included reviewers

4. Working with Azure Boards? Enforce linking a work item as a requirement on pull requests

Using Azure Repos and Pipelines, you may also be using Azure Boards also. This recommendation is great if so, you can enable check for linked work items as a requirement. This encourages traceability by checking for linked work items on pull requests.

Configuring Check for linked work items:-

• Select the branch you want to configure and select … (to right of branch) -> Branch Policies
• Review as below Check for linked work items

Can be set to required or optional, I do recommend required and as mentioned this will encourage traceability in relation to the change and pull request.

5. Build Validation

A favourite of mine, build validation! Validate code by pre-merging and building pull request changes. Its just awesome!

I have blogged Validating Terraform Code During A Pull Request In Azure DevOps which shows build validation in action.

Configuring Build Validation:-

• Select the branch you want to configure and select … (to right of branch) -> Branch Policies
• Review as below Build Validation

Adding a build policy by selecting + on Build Validation.

Below is the build policy I added:-

• Build pipeline:- Assign the pipeline that will be ran as build validation during pull request
• Trigger:- Automatic
• Policy requirement:- Required
• Build expiration:- Immediately
• Display Name:- Accurate display name of the build validation

6. Lock a Branch

Don’t be afraid to lock a branch until such times it is actually required to have updated code merged. Possibly develop -> master.

When a branch has been locked, it prevents any user from changing the existing commit history and also blocks from any new commits from being added to the branch by other users also.

Locking is ideal for preventing new changes that might conflict with an important merge or to place a branch into a read-only state.

How to lock a branch

Select the branch you want to lock and select … (to right of branch) -> Lock

Thanks for reading – hopefully these 6 recommendations get you started on thinking about further branch security ideas.