Microsoft Azure has been a popular platform for various kinds of cloud computing for years, and, more specifically, Azure DevOps Services caters to developers and their DevOps teams very specifically, weaving tightly into an organization’s software supply chain and lifecycle.
As with any cloud-based solution, security must always be the topmost concern. Today, we will offer some Azure DevOps security best practices to ensure you get the most benefit out of the service without unnecessarily putting your code at risk.
Key highlights:
- Azure DevOps security is the practice of protecting code, identities, pipelines, and configurations throughout the software development lifecycle.
- Applying Azure DevOps security best practices, such as hardened repository policies, is essential to preventing unauthorized changes and code tampering.
- Avoiding common misconfigurations and continuously validating security posture helps reduce exposure across projects and service connections.
- Cycode secures Azure DevOps by providing unified visibility, continuous validation, and automated enforcement across source code, workflows, and user accounts.
What Is Azure DevOps Security?
Azure DevOps security is the collective set of controls and strategies used to defend your code, pipelines, and developer identities from exploitation. It is the foundation of Azure DevOps security compliance because it ensures every component of your CI/CD process is hardened against unauthorized access and supply chain attacks.
In a modern DevSecOps environment, security is integrated rather than a perimeter. It involves validating configurations, securing service connections, and maintaining total visibility over who can access your intellectual property.
Best Practices for Azure DevOps Advanced Security
Getting “Advanced Security” right in Azure DevOps means moving past defaults to eliminate the vulnerabilities attackers love. Use these Azure DevOps security best practices to harden your environment without slowing down your sprint velocity.
1. Enforce Strong Identity Boundaries
Identity is the new perimeter. If your identity boundaries are porous, your code is public. Start by integrating Azure DevOps with Microsoft Entra ID to centralize management and enforce the principle of least privilege.
- Kill Shared Accounts: Every action must be tied to a unique identity. Use service principals for automation and Personal Access Tokens (PATs) only when necessary and with short lifespans.
- Context-Aware Access: Use Conditional Access policies to ensure users are only logging in from managed devices and known locations.
2. Implement Secure Pipeline Governance
Pipelines are the most direct route to production. Secure SDLC governance ensures that your build definitions are immutable and protected from malicious injections.
- Standardize with YAML: Use centralized and read-only YAML templates for builds to prevent unauthorized steps from being added to individual pipelines.
- Enforce Deployment Gates: Never allow a build to hit production without automated quality gates and manual sign-offs from designated stakeholders.
- Automate Code, Secrets, and Dependency Scanning
Security should not rely on human memory. Automated code scanning catches vulnerabilities in your proprietary logic while secrets detection ensures that no API keys or credentials accidentally end up in your commit history.
- Shift Left: Integrate SCA (Software Composition Analysis) to block builds that introduce high-risk or vulnerable third-party packages.
- Real-time Secrets Blocking: Use pre-receive hooks to stop secrets from ever reaching the server and save your team the headache of rotating leaked credentials.
- Enforce Branch Protection and Commit Integrity
Your main branch is your most valuable asset. Branch protection policies ensure that every line of code is vetted before it is merged to prevent unauthorized commits.
- Mandate Peer Reviews: Set a minimum number of reviewers for PRs and ensure those reviewers cannot be the original author of the code.
- Signed Commits: Require GPG signing for all commits to verify that the person pushing the code is actually who they claim to be.
- Harden Service Connections and Machine Identities
Service connections are often the weakest link because they act as persistent keys to your cloud infrastructure. Treat these machine identities with the same scrutiny as human accounts.
- Scope to the Resource: Do not use “Contributor” roles at the subscription level. Scope service connections to the specific Resource Group they need to manage.
- Workload Identity: Transition to Workload Identity Federation to remove the need for long-lived and static secrets that are prone to leakage.
6. Monitor SCM and Pipeline Activity for Anomalies
A “set it and forget it” mentality leads to breaches. Continuous monitoring of your SCM and build logs is the only way to catch insider threats or compromised accounts in real time.
-
Watch for Mass Activity: Set alerts for anomalous behavior like a user suddenly cloning dozens of repositories or changing organization-level security policies.
-
Audit Log Streaming: Export your logs to a dedicated security platform to ensure you have a tamper-proof trail for forensics and compliance.
7. Validate Compliance and Detect Configuration Drift
Configuration drift happens when teams move fast. Maintaining SDLC compliance requires automated tools that can detect when a repository visibility changes or when a protection policy is disabled.
-
Automated Remediation: Use tools that do more than just alert on drift. Choose solutions that automatically reset settings to their hardened and compliant state.
Visibility Audits: Periodically audit for public projects or repositories that may have been created accidentally during a testing phase.
Understanding Azure Authentication and Access Controls
The Azure DevOps web platform defaults to leveraging Microsoft-managed identities for authentication, which means you’ll need to log in to your own Microsoft account in order to configure account-level security and control access.
When a user first logs on, an Active Directory organization is automatically created for them, and you should connect your organization in order to support more advanced login restrictions. Doing so will enable you to create policies to safeguard and restrict access to the organization. (For example, if your organization has its own internal Active Directory service, then you can integrate it with Azure’s Active Directory.)
Let’s review some of the most important advanced security settings.
Multi-Factor Authentication
Multi-factor authentication, or MFA, is the most basic security feature available. It should be a company’s de facto policy to require all employees and contractors to use MFA.
Assuming you have an Azure Active Directory already set up, do the following:
- Log in to Azure (the main Azure portal, not the Azure DevOps portal).
- Select the Azure AD Conditional Access service. (The easiest way to find it is by navigating into Azure services, then using the “all services” search bar.)
- Under the Conditional Access menu, you can define policies regarding access and authentication. For example, if you wanted to require MFA for all users, you could enable the “Require MFA” policy and configure it like this:
A detailed explanation of how to create an MFA rule for all users can be found here.
Limit Access by Location
You can also set policies to limit access to specific locations. Simply log in to Azure and navigate to Azure AD Named Locations.
For example, you can configure a location so that MFA is not required for internal (intranet) IP addresses:
Single Sign-On
Security Assertion Markup Language (SAML) for Single Sign-On (SSO) is available within the Azure ecosystem. If you’re familiar with SAML SSO, you know it’s an excellent option for helping ensure secure user logins across the organization. Since Azure AD itself serves as the Identity Provider, there is a wide range of simple to advanced SSO configuration options available. Azure’s official reference guide offers more information.
Securing Azure Projects, Repositories, and Branches
Access plays a critical role in advanced security for Azure DevOps. Permissions can be applied to a user or a group of users and are determined by both the access level and the security group assigned to a user. Let’s take a close look.
Understanding Access Levels and Security Groups
You must first select whether a newly added user to your organization will be granted Basic or Stakeholder permissions. The Basic and higher access levels support full access to all Azure Boards features. Stakeholder access provides partial support to select features, allowing users to view and modify work items without having access to all other features. Stakeholder access is available to support free access to a limited set of features by an unlimited number of stakeholders. Check here for more details.
Setting Project-Level Permissions and Access Controls
Once you have created an Azure DevOps project, you’ll find project settings at the bottom of the left-hand menu in your DevOps dashboard:
Next, you’ll find a Permissions menu item under the General section:
Here we can find the security groups discussed in the previous section:
We can edit the permissions of a user or group of users. Permissions are divided into General, Boards, Analytics, and Test Plans, each section controlling the relative permissions. When you select a group, you’ll be taken to the following settings specific to that group:
Check here to learn more about these various permissions.
Managing Permissions for Repositories
While we’re in our project settings, let’s next turn our attention to the “Repositories” menu item, found in the left-hand menu under the “Repos” section.
Here we’ll find repository access permissions specific to the current project. We can tweak many permissions here, not least of which are settings for who can view and modify the repository’s content:
Granular permission controls can be configured according to the project’s needs, which you can read more about here.
Enforcing Branch Protection and Preventing Tampering
Azure DevOps supports creating branch protection policies, which protect the code committed to the main branches. (We’re a big proponent of using protected branches, which we’ve covered for other services.)
The most basic policy you should always have enabled pertains to prohibiting any code changes without first undergoing a review. The “Require a minimum number of reviewers” setting ensures that every piece of code committed to the main branch is reviewed by at least one other developer.
To configure this and other related policies, navigate to your project settings, then to the repositories menu. Next, select the repository you want to set policies for. Navigate to the Policies tab, scroll to the Branch Policies section, then select the branch you want to set a policy for.
Once the branch is selected, you can toggle on the policies you want to enforce:
(If you would rather set branch protection policies for all of a project’s repositories at once, switch over to the Policies tab without selecting a specific repository, then scroll down to the “Branch Policies” section.)
Use the “+” button to create a new policy, at which point you’ll be presented with the option to either protect each repository’s default branch or all current and future branches of all repositories that match a certain pattern:
Before moving on from Repository Policies, take note of some other potentially useful policies found here. “Commit author email validation” requires developers to use their corporate email when committing. “File path validation” may be utilized to protect the repository from commits that include sensitive content.
Finally, navigate to the Permissions tab to designate who can bypass currently enabled policies. These settings can be found on the far right-hand side of the screen:
Preventing Source Code Leakage and Unauthorized Visibility
Source code is the crown jewel of your intellectual property, and its exposure can lead to credential theft, exploit development, or loss of competitive advantage. Implementing rigorous visibility controls protect source code by validating that repository settings align with corporate security policies. This proactive approach ensures that only authorized users have access to your internal logic and prevents accidental exposure to the public internet.
Controlling Forking and Repository Duplication Risks
Forking is the act of creating a copy of the repository to allow developers a safe environment where they can experiment on the code without affecting the original, which minimizes risk.
There are two main issues with forking from a security perspective. First, the more forks there are for a repository, the harder it is to keep track of each fork’s security. This challenge grows exponentially the more forks a repository has. Second, a user can easily fork a copy of a repository to their own private account.
Forking can be disabled via the project’s repository settings. Simply select the repository and toggle the “Forks” setting to “Off”:
Managing Visibility and Restricting Public Access
Azure DevOps allows controlling project visibility through two main mechanisms.
First, you’ll find a “Visibility” setting at the top level of your project settings, via the Overview menu item under the General section. You may set visibility here to public or private:
You can learn more about project visibility here.
Second, you can disable public projects altogether at the organization level by first navigating to the Organization Settings, then to Policies (under the Security section). Here, you may disable “Allow public projects” by toggling the button to “Off”, thus disabling support for all projects across the organization.
Monitoring, Auditing, and Investigating Anomalous Activity
Within your organization settings, you can access audit events for your Azure DevOps organization. Periodically review audit events and make sure that there are no anomalous or suspicious activities.
Common Azure Misconfigurations DevOps Teams Should Avoid
Misconfigurations are the most frequent entry point for attackers in cloud-native environments. Even with advanced tools, a single oversight in your organization settings can compromise your entire software supply chain.
Avoiding these common pitfalls requires moving beyond “default” security and implementing a policy-driven approach to your DevOps infrastructure.
Overly Permissive Access and Default Privileges
One of the most dangerous misconfigurations is granting users more access than their role requires. High-level permissions like “Project Administrator” or “Build Administrator” are often handed out for convenience, creating a massive blast radius if a single account is compromised.
- Apply Least Privilege: Regularly audit your Security Groups and move users to the “Basic” or “Stakeholder” levels unless they specifically require administrative rights.
- Avoid Individual Permissions: Assign permissions to groups rather than individual users to simplify auditing and prevent “permission creep” as team members change roles.
Missing or Weak MFA and Conditional Access Policies
Relying on passwords alone is a critical failure in modern AppSec. Without Multi-Factor Authentication (MFA) and location-based access restrictions, your SCM is highly vulnerable to credential stuffing and phishing attacks.
- Enforce Conditional Access: Use Microsoft Entra ID to mandate MFA and restrict logins to known, managed corporate devices.
- Review Service Principal Security: Ensure that machine identities and service principals are not exempt from your organization’s strict authentication requirements.
Unrestricted Pipeline Permissions and Agent Exposure
Pipelines that run with elevated privileges can be used as a pivot point to attack your cloud infrastructure. If a build agent is compromised and has unrestricted access to your Azure subscription, an attacker can move laterally across your entire environment.
- Scope Service Connections: Restrict each service connection to the specific Resource Group or subscription it needs, rather than granting “Contributor” access at the top level.
- Use Ephemeral Agents: Shift to Microsoft-hosted or containerized agents that are destroyed after every build to ensure that malicious code cannot persist between jobs.
Insecure Repository Settings and Public Project Visibility
A simple toggle can turn a private project public, exposing your proprietary source code and hardcoded secrets to the world. Many organizations fail to disable “Public Projects” at the organization level, leaving them one click away from a massive leak.
- Disable Public Projects: Toggle “Allow public projects” to Off in your Organization Settings to ensure all new projects default to private.
- Limit Forking: Disable forking for internal repositories to prevent developers from duplicating sensitive code into private, unmonitored accounts.
Improper Secrets Handling and Unsecured Service Connections
Hardcoding API keys, database strings, or certificates in YAML files or scripts is a high-risk practice. Once a secret is committed to a repository, it remains in the history forever, even if the line is later deleted.
- Use Azure Key Vault: Store all sensitive variables in a dedicated vault and reference them dynamically during the build process.
- Audit Service Connections: Regularly rotate the credentials for your service connections and remove any that are no longer actively used by your pipelines.
Essential Azure DevOps Security Tools for Enterprises
Securing an enterprise-scale Azure DevOps environment requires a layered toolchain that covers everything from the developer’s IDE to the production cloud.
The following categories represent the essential components of a modern, automated security stack.
Identity and Access Security
Strong identity management is the foundation of a secure SDLC. Enterprise tools in this category focus on centralizing authentication and ensuring that every human and machine identity is verified and governed.
- Specific Tools: Microsoft Entra ID (Azure AD), CyberArk, Okta, and Azure Privileged Identity Management (PIM).
Code and Pipeline Security
Protecting the integrity of your code requires continuous scanning for vulnerabilities and pipeline tampering. Implementing modern app security practices ensures that your CI/CD workflows are resilient against supply chain attacks.
- Specific Tools: GitHub Advanced Security for Azure DevOps, SonarQube, Snyk, and Checkmarx.
Cloud and Configuration Hardening
Cloud Security Posture Management (CSPM) tools are vital for detecting drift and misconfigurations in your Azure environment. These tools ensure that your infrastructure as code (IaC) is secure before it is even provisioned.
- Specific Tools: Microsoft Defender for Cloud, Wiz, Prisma Cloud, and Checkov.
Secret and Credential Protection
Credential leaks are one of the fastest ways to suffer a breach. Dedicated tools for detecting secrets scan your entire commit history and real-time pushes to find and block exposed tokens and keys.
- Specific Tools: Cycode, GitGuardian, and Azure Key Vault.
Audit and Monitoring
Monitoring tools provide the necessary visibility to catch anomalous activity as it happens. These solutions aggregate logs from across your DevOps stack to provide a clear audit trail for compliance and forensics.
- Specific Tools: Azure Monitor, Microsoft Sentinel, Splunk, and Datadog.
Third-Party AppSec and Supply Chain Tools
Modern applications are built on open-source libraries, making your supply chain a major target. Utilizing specialized application security tools allows you to inventory your dependencies and block vulnerable components.
- Specific Tools: Cycode, Mend.io (formerly WhiteSource), and JFrog Xray.
Selecting the Right Azure DevOps Tools to Manage Security
Choosing the right tools isn’t just about checking a box; it is about reducing complexity and alert fatigue. When evaluating security solutions for your Azure DevOps environment, consider the following:
- Platform Integration: Does the tool feel native to the developer workflow, or is it a “bolt-on” that adds friction?
- Context-Aware Risk: Can the tool prioritize vulnerabilities based on reachability and production impact, or does it just bury you in a mountain of “High” alerts?
- Breadth of Coverage: Look for a platform that consolidates SAST, SCA, secrets detection, and CSPM into a single pane of glass.
- Automated Remediation: Prioritize tools like Cycode that don’t just find problems but offer automated PRs and developer-friendly guidance to fix them fast.
Cycode Makes
Cycode can help you with all of the above (and more!) by automatically inspecting the security posture across Azure DevOps’ various settings. We analyze the actual usage and recommend tightening the access model to fit a least-privileged approach. We monitor SCM activity in real-time, allowing us to alert you to various security-related incidents based on the policy that best suits your organization.
Book a demo today and see why enterprises trust Cycode to help them maintain Azure DevOps security best practices.
