Azure DevOps Security Best Practices

Last Updated on November 14, 2024

Data-handling platforms such as Azure DevOps are often relied on by many different modern organizations, therefore it is important to secure such environments. These widely used platforms simplify DevOps processes like project management and the work of developers.

However, there is a downside, the rise of technology brings an increased risk of cyber attacks. To deal with these your organization must prioritize security, implement data protection procedures, including backup for Azure DevOps, and review the most up-to-date best practices. 

Potential risks concerning Azure DevOps

As we started discussing, since DevOps is a very prominent and consistently growing market, it attracts the interest of many threat actors. Risks include accidental deletions due to human error as well as intentional deletions by malicious employees, which then, lead us to unauthorized access. Another huge threat is ransomware, which, without backup copies of your work and disaster recovery procedures in place, is a truly deadly weapon that can leave organizations in total chaos – huge costs, damaged reputation, missed deadlines, and lost clients. Just to put the current cyber threats into perspective, the IBM Cost of a Data Breach Report 2024 states that the average cost of a data breach is 4.88 million dollars – a 10% increase from 2023. 

Moreover, due to the extensiveness and complexity of current DevOps ecosystems, errors that lead to platform outages take place too. A significant outage of Azure DevOps services happened in 2022 when European users experienced degraded performance and even complete unavailability of Boards, Repos, Pipelines, and Test Plans, which are rather critical services for many companies. Here is a comment Azure DevOps users could see on the service’s status page:

Source: The Register

Shared Responsibility Model 

Microsoft works following the Shared Responsibility Model, which is a division of duties between the SaaS provider and the customer. Microsoft outlines in their documentation that in terms of SaaS, its responsibilities are the following:

• physical data centers,
• physical network,
• physical hosts,
• operating systems,
• network controls,
• and applications.

Identity and directory infrastructure are shared duties by both parties. You, as the user, are responsible for your data, endpoints, accounts, and access management. The elements which you can impact in terms of security are important to pay attention to since you can directly improve them. Implement strict access controls, follow industry best practices, back up your data, and make sure you are ready for any disaster scenario.

Source: Microsoft: Shared Responsibility in the Cloud

Azure DevOps security best practices 

To keep your Azure DevOps data secure – both Server (on-premise) and Services (cloud), there is a range of procedures and best practices to follow. Whatever you learn in regards to securing your Azure DevOps stack, you should educate your team on it, to raise awareness and guarantee consistency in terms of security measures across your organization. 

Identity and access controls 

Azure DevOps is a broad ecosystem (code repositories, pipelines, boards, artifacts, test plans, and more), which plays an important role in modern software development. It encompasses critical data, from configuration settings to actual source code. Therefore, you should restrict access according to the principle of least privilege for all users, and carefully manage permissions along with access control to enhance the security of data in Azure DevOps. Moreover, you should have different access levels for individual users or roles and never leave default permissions unchanged.

Restrict, monitor, and control access 

In modern software development, teams often work remotely and different employees are responsible for specific areas and processes. The last thing you want is confusion in terms of permission management, leaks, or deletions of critical data by accident or by malicious individuals. Therefore, it is necessary that you carefully implement strict access control across your Azure DevOps environments, and then manage them effectively. 

• Adopt the principle of least privilege. Restrict user access to minimum required permissions – the resources employees require for their tasks. If a member of your team needs access to data outside of their usual needs, you can give them temporary access. Now, you not only reduce the risk of intentional and accidental deletions thanks to limited access, but you also keep your organization more transparent, easier to manage and, also, simplify the audit process. 
• Use Role Based Access Controls (RBAC), to guarantee that there is no excessive access to sensitive areas of your infrastructure. RBAC allows you to have roles, that have predefined permissions assigned, and then you simply assign those roles to users. This could simplify your access management as limitations do not have to be customized for each user but are instead pre-established for specific roles with access levels. 
• Regularly review the granted access and make sure to implement proper access level management. Monitor the logs in order to be aware of any potential suspicious actions or access attempts. If anything raises alarms, deny permissions. Also, remember to disable and remove user accounts that are inactive. Such accounts open up the possibility of a malicious individual accessing your infrastructure and causing damage. 

Multi-factor authentication 

A strong password is the foundation of securing your data. However, even strong 16-character passwords with upper and lower case letters, special signs, and numbers can be broken. How to strengthen your password? Implement 2FA (2-factor authentication) or MFA (multi-factor authentication). With 2FA as an extra layer of security, you guarantee that apart from your password and login credentials, there must be another verification step to access the account, and that step is only known to you. This could be authenticated through getting a text message to your number or receiving an email or a call. 

Alternatively, to further secure your account, you could implement multiple-factor authentication. This way there will be several verification steps apart from the usual password and username. So, if an attacker attempts to access your account, you have many required pieces of information and devices to authorize access, which are only known to you. 

Use Microsoft Entra ID 

If you are looking for a way that would encompass different security features into one, an IAM solution might be a good idea. A cloud identity and access management service (IAM), Microsoft Entra ID, helps organizations manage user identities and access control to a range of internal as well as external resources. With it comes SSO (Single Sign-On), which allows you to access multiple apps with the same credentials. You also get Multi-Factor Authentication (MFA) and the possibility to set access controls based on the user information, such as risk level, the state of their device, or its location. The service is free but you can also add paid features to it. This way you can narrow down your authorization process to just one service. Although convenient, there is still a need to outline and analyze the practices required to secure your Azure DevOps infrastructure – in-depth and one by one. 

Create security groups 

Managing large projects and extensive teams can be difficult in terms of keeping all processes and data secure. If you create custom security groups, it helps to manage permissions and access. So, for example, project managers could simply be assigned to the relevant group with predefined permissions for their role. Also, Azure DevOps has default security groups ready to be used. 

Let’s take a look at some of the main commands that can help you with the process of creating and managing security groups in Azure DevOps. 

• To create a security group you can use: ‘az devops security group create’. 
• If you need to delete security groups use: ‘az devops security group delete’. 
• Add users to security groups through: ‘az devops security group membership add’.
• Remove group members from security groups with: ‘az devops security group membership remove’. 

Ideally, you should limit access to repos and projects, disallow public project creation within your organization, and prevent users from creating new projects without confirmation. 

Have credentials and authentication security 

Protect your account by keeping your credentials secure, and implementing an effective authentication process. You can take an extra step and use Personal Access Tokens (PATs) instead of the usual passwords. PATs are a long string of random characters that you can use to securely authenticate and access a service or system. 

Alternatively, you can also use SSH keys, which consist of a private key assigned to the user and a public one, that’s shared with the server. You can also add a passphrase to your private SSH key, to further secure access to it. However, there are a couple of pointers and recommended practices for using PATs and SSH keys. 

How to securely use PATs and SSH keys? 

Whether using PATs or SSH keys for Azure DevOps services, you should restrict them to the required minimum permissions. This way you can reduce the risk of unauthorized changes. You should also review all SSH keys and PATs, and revoke the ones which are not being used to minimize the risk of unwanted access by an old employee for example. Then, rotate both SSH keys and PATs regularly.

By doing so, you can make sure that if a token or keys get exposed, their lifespan is limited and the ones that are compromised can’t be used long-term. Note that with SSH keys you need proper management of those in terms of rotation as well as the generation of environment-specific keys. Moreover, you can protect your keys with a passphrase and even generate them on a hardware security key. In contrast, PATs can have set permissions as well as expiration dates. 

Also, remember that your SSH keys or PATs should not be hardcoded into your code within a repository, as it brings the risk of accidental exposure. What you could do instead is to use Azure Key Vault to store your PATS and SSH keys and securely retrieve them when needed. 

Keep your network safe 

In order to securely use Azure DevOps you should follow recommendations that help to keep your network safe. Start off by restricting access to only specific IP addresses. This way you only allow traffic from trusted sources. Then, you should also keep your data encrypted – both at rest and in transit, and secure channels of communication through the use of HTTPS or other relevant protocols. As an extra step towards security, add web application firewalls (WAFs). This way you can monitor, as well as block any malicious traffic. Last but not least, whenever establishing connections, always make sure that certificates are valid and that trusted authorities have issued them. 

Verify third-party integrations 

Microsoft’s Azure DevOps can integrate with several useful applications, such as Microsoft Teams, and allow users to receive Azure notifications there. However, it is crucial to thoroughly understand and verify such apps before integrating them into your stack. Before you choose to add an application to upgrade your CI/CD, check its reviews, who created it, and if it is compliant with industry security requirements and standards like ISO 27001 or SOC 2. 

Pay attention to GitHub integrations 

When integrating GitHub with your Azure DevOps you will need to disable authentication through PATs and opt for OAuth flow to improve security. Also, don’t use owner or admin identity for authentication of GitHub service connections. Remember, always access to the bare minimum. Then, make sure that no personal GitHub accounts are used as service connections within Azure DevOps; for that, you should have dedicated accounts. 

Monitor processes through logging & auditing 

When it comes to complex infrastructures, it is important to track activities taking place. Moreover, if you’re dealing with a lot of employees, it could be beneficial to monitor processes through logging actions, and auditing. That, in turn, can allow you to pinpoint areas for improvement and spot potential vulnerabilities or risks within your organization. Any security incidents should be reviewed thoroughly and communicated to all teams. 

Secure your repositories and branches 

Repositories often store critical information and require proper security measures. No one wants threat actors accessing, or even worse, damaging their source code. Make sure that access to repositories is restricted. Any pull requests should get reviewed by at least two different individuals before getting approved. This supports thorough checks and reviews of code and also increases accountability. Project requirements differ from one another, so, to guarantee comprehensive protection, you should implement customized security policies for specific repos and branches. 

Now, if there are any secrets related to production, these can be separated from the main branch and stored in an Azure Key Vault. Make sure that you limit access to only those individuals who require access to finish their tasks. Moreover, managing permissions is also a key aspect! This way you further protect your secrets and avoid mixing branches, especially your testing environments with production. This also helps to keep operations transparent and organized.

What is more, your Azure DevOps environment should go through scanning and checks to support DevSecOps. Thus, you can eliminate any secrets from getting to production environments, improve the quality of code, and easily track relevant processes. Thankfully, Microsoft has a suite of tools to accommodate this – GitHub Advanced Security, which provides you with: 

• Testing tools native to Azure DevOps 
• Secret scanning 
• Code scanning 
• Dependency scanning

Moreover, you should implement scanning as a regular aspect of your CI/CD pipelines. This way you can continuously verify the security and integrity of your branches and repositories. 

Don’t allow forking 

Another important factor in Azure DevOps is git forking. Although useful in terms of making a copy of a project and then editing it without affecting the main branch, it raises some security issues. Namely, it complicates the tracking of processes, and as a result, slows it down. Additionally, by giving individuals the ability to simply make a copy of repos that your teams have spent days or even years building, it puts your organization at risk. Imagine if there was a temporary developer on your team or a person who is about to leave your company; what if they fork crucial builds and take advantage of it for their personal use or even for financial gain? The results could be gruesome and costly… 

If you do allow forking in certain situations, make sure there are no secrets stored in the repos that are open for forking. Then, to further secure the process of forking, only allow manually triggered forking to support confidentiality and control over security reviews. 

Add specific rules and policies for branches 

In order to put knowledge into practice and simplify security processes, you should set specific policies for different branches and general rules for repositories. Now, in order to set any branch policies, you need to be a member of the security group for Project Administrators or have the permissions for “Edit policies” at the repository level. 

Ideally, your policies should cover the aforementioned requirement of a minimum number of reviewers. Also, make sure that only relevant and verified individuals can access repositories and specific branches. Moreover, you need to guarantee that only trusted contributors are approved to make any changes. Plus, any code that is about to be imported into your Azure DevOps should be checked and audited. Amongst others, you also need to pay attention to clearly defining roles and their required permissions as well as implementing a standard for password rules. 

Policies and rules will vary depending on the types of organizations, specific repositories, and different branches. These should be thoroughly evaluated, discussed with security officers as well as development teams, and effectively implemented across the company and your Azure DevOps environment. 

Create a SECURITY.md file 

Adding a SECURITY.md file to your development processes within Azure DevOps is beneficial for a number of reasons. What separates a README.md file from a SECURITY.md file is the fact that the former only includes a basic overview of a project, whereas the latter includes a set of procedures that must be followed while reporting security vulnerabilities in projects. 

A SECURITY.md file should cover a disclosure policy – how to communicate the discovered information and the specific person that should be contacted. Also, include a security update policy, that will describe the process of communicating a vulnerability to relevant individuals. Then, you need a security-related configuration that provides the required settings to improve the security of a project during deployment. Lastly, include any known vulnerabilities and possible enhancements for the future that aren’t yet implemented. 

Back up your Azure DevOps data 

To avoid data loss and downtime in case of ransomware attacks, accidental deletions, or outages, you should regularly back up your work. Ideally, the process should be automated to avoid human error and allow your employees to focus on their primary tasks. Backups help to keep your Azure DevOps data recoverable. When choosing a backup vendor, make sure that the following criteria are met: 

• Full data coverage (repositories, metadata, and relevant Azure DevOps services)
• Automation along with scheduling of backup processes 
• The ability to choose your storage (convenient to use Azure Blob)
• Unlimited retention (great for archiving purposes, compliance, and restoring data from a specific point in time)
• Compliance with industry standards like SOC 2 Type II or ISO 27001 
• Meet the 3-2-1 backup rule (at least 3 copies across 2 different storage instances, with 1 being stored off-site) 
• Ransomware protection 
• Encryption (including in-flight and at-rest data encryption, you should be able to use your own key too) 
• Flexible restore and recovery capabilities (point-in-time restore, granular restore, full data recovery, cross-over recovery – in case Azure DevOps services are down)

Service-specific security 

Since Azure DevOps services are rather comprehensive, you need to pay attention to secure all of the services within it that you use. For Azure Artifacts, you need a clear understanding of the differences between project collection administrators, feeds, and projects, and set feed permissions.

As for Azure Boards, set plan permissions and work tracking, and then, configure Azure Boards before making changes to a process. Additionally, you can customize query permissions.

With Azure Pipelines, you should customize pipeline settings in terms of permissions and make use of extended templates.

We already covered the security of Azure Repos but let’s reinforce the need for proper access management and branch-specific policies to keep your code secure.

Last but not least we have Azure Test Plans, for which you also need to set appropriate permissions for testing. 

By adhering to the security best practices across all of your Azure DevOps services, you guarantee that your data is protected and that not a single aspect of your infrastructure is left vulnerable to any security risks. 

How to improve your security posture with GitProtect

To fully protect your Azure DevOps data, it is important to implement a reliable backup and DR solution into your security strategy. With GitProtect backup for Azure DevOps, you can automate and monitor your backup processes as well as recover data using flexible restore options. GitProtect is compliant with a range of industry standards such as SOC II type 2 and ISO 27001. It can further support your compliance efforts, for example, by simplifying audits.  

Extensive backup coverage that encompasses all your Azure DevOps data is key to a complete cyber-defense strategy. As a comprehensive backup and DR solution, GitProtect secures Azure DevOps repos along with metadata for both Azure DevOps Server and Cloud options. With this backup software, your coverage will include repositories and their content, LFS, pull requests with labels and comments, projects, work items along with comments and attachments, project wiki, pipelines, environments, variable groups, processes, and work item types including their layouts and states. 

Last but not least, you should pay attention to comprehensive monitoring capabilities. This is significant in order to keep track of backup tasks and restore processes related to your Azure DevOps services. Therefore, with GitProtect you get a central management console and data-driven dashboards. These include statistics regarding your ecosystem’s security, the latest backup and restore processes, compliance strength summaries, SLA audits, and monthly reports. You can also customize your email notifications or alternatively, set up Slack or Webhook notifications. This level of monitoring and alerting allows you to have a better overview of your organization’s processes and enhance Azure DevOps security.

[FREE TRIAL] Ensure compliant Azure DevOps backup and recovery with a 14-day trial🚀

[CUSTOM DEMO] Let’s talk about how backup & DR software for Azure DevOps can help you mitigate the risks

Before you go:

🔎 Find out how to build a reliable backup strategy for your Azure DevOps environment within the backup best practices

📚 Learn how to make sure that your Disaster Recovery strategy for Azure DevOps is effective

✍️ Stay up-to-date with the latest DevSecOps insights – subscribe to GitProtect DevSecOps X-Ray Newsletter