Azure DevOps Services – Security Checklist

Azure DevOps Services Security Checklist
Table of Contents

Microsoft Azure DevOps Services is a cloud-hosted platform that provides end-to-end DevOps capabilities for building software, from planning through deployment. The platform employs a number of security concepts and controls to ensure your projects are safe, private, and available.

This blog provides a checklist you can use to enforce the security of your environment in Azure DevOps, and make the most of the platform.

1. Control access

You should control access to your Azure DevOps Services environment by assigning and publishing roles and responsibilities. By stipulating clear lines of duties, you can minimize the confusion that can lead to human and automation mistakes that can cultivate security risks. It’s the best way of ensuring that only authorized users can access the functions, features, and data of the specified Azure DevOps assets. 

Azure DevOps Services provides two main inter-connected ways of controlling and governing users’ access:

  • Permission management
  • Access level management

Permission management

Permissions in Azure DevOps either permit or deny access to a feature. They can be set at various levels for most objects within the platform, such as area paths, pipelines, and repositories. If users are added to a security group, they inherit the permissions assigned to that group. A security group defines the scope of tasks its members can undertake.

If you create an organization, collection, or project, Azure DevOps also automatically creates a set of default security groups with default permissions. You can also create custom security groups with your own defined permissions. 

For example, to find the security groups, start by clicking Project settings on your project’s dashboard sidebar:

Azure DevOps dashboard project settings

Then, under the General section, select the Permissions option:

Azure DevOps dashboard Permissions option

You’ll see a list of the built-in security groups. You can click on any of them to set and edit specific permissions, add users to the group, or configure other settings. You can also click the New Group button to create a customized permission group.

For example, here are the settings specific to the default Build Administrators security group:

Azure DevOps Build Administrators group permissions

Access level management

Access levels in Azure DevOps Services allow or deny access to the platform’s features. This is in addition to the permissions set via security groups.

These are the access levels supported:

  • Basic—provides access to most of the platform’s features. 
  • Stakeholder—provides partial access. It’s suitable for users who require access to a limited set of the platform’s features.
  • Visual Studio Subscriber—this is assigned to users who already have a Visual Studio subscription. 

To give users access to your organization, start by going to your organizations’ dashboard. Then, after selecting your preferred organization, click Organization settings on the sidebar:

Azure DevOps organization settings

Next, under the General section, select the Users option. On the ensuing page, click the Add users button. 

Azure DevOps add users

On the resulting popup, add the new user(s) details, while defining their access level. Lastly, click the Add button to complete the invitation.

Azure DevOps add new users’ details

Once you’ve added a user, you can view and edit some of their information. For example, if you want to manage a user, just click the More… ellipsis at the end of the user’s information. Then, you’ll be able to complete various user management tasks, including changing their access level. 

Azure DevOps manage users

2. Control visibility

Azure DevOps Services allows you to change the visibility of your projects from public to private, and vice-versa. If users have not signed in to your organization, they have read-only access to your public projects. Conversely, if users have signed in, they can be granted access to private projects and make any permitted changes to them.

There are two ways of controlling the visibility of projects in Azure DevOps:

  • Using project settings
  • Using organization settings

Using project settings

On your project’s dashboard, click Project settings on the sidebar:

Azure DevOps add users

Next, under the General section, select the Overview option. You’ll then find the Visibility setting on the top level of the page. You may set your desired visibility status here, either public or private. Finally, click the Save button to complete the changes. 

Azure DevOps change project visibility via project settings

Using organization settings

On your organizations’ dashboard, select your preferred organization and click Organization settings on the sidebar:

Azure DevOps change project visibility via organization settings

Next, under the Security section, select the Policies option. On the ensuing page, under Security policies, you can toggle the button on or off.

Azure DevOps organization security policies

If the button is on, it enables anonymous access to your organization’s projects. On the other hand, if it’s off, it disables public access to your organization’s projects.

3. Protect repositories from tampering 

Azure DevOps allows you to enact policies that safeguard your project’s repositories and branches from tampering. 

These are the tasks you can do to protect your repositories from tampering:

  • Set repository and branch policies
  • Set repository and branch permissions
  • Disable forking

Set repository and branch policies

To set the policies, start by navigating to your Project Settings menu. Next, on the Repos section, click the Repositories option. Choose the Policies tab and set your desired protection policies for all repositories in your project.

Azure DevOps set repository policies

For example, if you want to block pushes from commit authors with suspicious email addresses, you can activate the Commit author email validation policy and set the necessary conditions. You may also set the File path validation policy to safeguard your repository from commits with sensitive content. 

If you scroll down the same page to the Branch Policies section, you can create project-wide branch policies. Creating and merging branches may introduce insecure code into your project’s main branch. So, configuring branch policies can minimize the risk, enforce change management standards, and improve your team’s code quality.

To add branch protection policies applicable across all repositories in your project, click the plus (+) button:

Azure DevOps add branch protection policies

Next, you’ll be provided with a popup that requires you to select how you wish to protect your branches:

Azure DevOps add branch protection

If you select the first option (“Protect the default branch…”), and click the Create button, you’ll be directed to a page where you can configure the project-wide branch policies.

Azure DevOps set project-wide policies

An important security policy you should always activate is the Require a minimum number of reviewers. This policy prohibits committing any code changes to the main branch before other developer(s) completes a review.

You can also configure security policies specific to each repository or branch, instead of project-wide policies. To do so, navigate to the Repositories tab and select your preferred repository:

Azure DevOps repositories

Next, select the Policies tab and configure policies specific to your chosen repository.

Azure DevOps set repository policies

If you scroll down the same page to the Branch Policies section, you can select a branch and configure its specific protection policies.

Azure DevOps set branch policies

Set repository and branch permissions

Another task you can do to protect your repositories from tampering is to set their permissions. To do so, go to the Permissions tab and tweak the permissions you want to enforce on all the repositories in your project.

Azure DevOps set repository permissions

You can also choose a specific repository and tweak its permissions individually:

Azure DevOps set specific repository permissions

If you scroll down the same page, you can select a branch and configure its specific permissions:

Azure DevOps set specific branch permissions

Disable forking

Forks are a great way of letting developers freely try out changes without affecting the original repository. However, forks may cause security risks to your project. 

Primarily, it’s difficult to keep track of the security of each fork, especially if your repository has a high number of forks. Also, if a user forks a copy of your repository to their private account, it further complicates tracking its security.

So, you may consider preventing users from automatically creating forks from your repository. To do so, select your preferred repository and, under the Settings tab, toggle the Forks setting to off. 

Azure DevOps disable forking

4. Review audit logs

Azure DevOps Services provides audit logs that occurred throughout your organization within the last 90 days. This allows you to check for anomalies or suspicious activities that may affect the platform’s security.

Audit events are recorded whenever a user within your organization makes changes to the state of an artifact. Examples include modifying policies or permissions, accessing features, creating resources, removing resources, and many others.

To review audit logs, start by going to your organizations’ dashboard. Next, select your preferred organization and click Organization settings on the sidebar:

Azure DevOps organization settings

Next, under the General section, select the Auditing option. On the ensuing page, you can review, filter, and export the audit events that occurred throughout your organization. 

Azure DevOps access audit events

5. Implement web application firewalls (WAFs)

Web Application Firewalls (WAFs) can protect your Azure DevOps Services deployment. If you configure WAFs, they can filter, monitor, and block any malicious web-based traffic to and from your Azure DevOps Services. 

A WAF will apply a set of rules that inspects the Azure DevOps traffic and detects any anomalies. This prevents intruders from carrying out different types of attacks, such as cross-site scripting and SQL injection.

6. Use Mend Bolt

Mend Bolt is a powerful extension that can help you reinforce the security of your Azure DevOps instance. It’s a free extension that automatically scans your projects and identifies security issues with the open source components. It’s the tool you need to leverage the power of open source technologies without putting your projects at risk. 

Integrating Mend Bolt with Azure DevOps will provide you with the following benefits:

  • Receive real-time alerts on open source security vulnerabilities. 
  • Receive recommendations for easily fixing vulnerable open source components.
  • Ensure the license compliance of open source components, including all dependencies’ licenses.
  • Receive up-to-date open source inventory reports for every build or project.

Conclusion

You can keep your Azure DevOps Services environment secure by controlling access, controlling visibility, protecting repositories from tampering, reviewing audit logs, and implementing WAFs.

Additionally, using the free Mend Bolt extension can help you identify vulnerable open source components in your project and safeguard your codebase from unauthorized intrusions.

Recent resources

What is LDAP Injection? Types, Examples and How to Prevent It

Learn what LDAP Injection is, its types, examples, and how to prevent it. Secure your applications against LDAP attacks.

Read more

How to Use Dependency Injection in Java: Tutorial with Examples

Learn how to use Dependency Injection in Java with this comprehensive tutorial. Discover its benefits, types, and practical examples.

Read more

Idempotency: The Microservices Architect’s Shield Against Chaos

Discover the power of idempotency in microservices architecture. Learn how to maintain data consistency and predictability.

Read more