First, we are super excited about bringing GitHub Advanced Security and Microsoft Defender for Cloud’s new Defender for DevOps capabilities to Azure DevOps customers! Additionally, two other major security initiatives are planned for Azure DevOps over the coming year. The first is focused on minimizing the risks associated with credential theft; the second, on making it easier to harden Azure DevOps organization configuration.
Customers using Azure Repos and Azure Pipelines have up to now been unable to take advantage of GitHub Advanced Security’s industry leading capabilities. We’re pleased to announce that GitHub Advanced Security for Azure DevOps will bring these capabilities to Azure DevOps, natively integrated into Azure Repos and Azure Pipelines. This brings the same secret scanning, dependency scanning, and CodeQL code scanning capabilities of GitHub Advanced Security right into the Azure DevOps environment that these teams are already familiar with.
In addition to helping developers find and fix vulnerabilities by integrating alerting and remediation guidance directly into the Azure DevOps experiences they already use every day, GitHub Advanced Security will also integrate with Microsoft Defender for Cloud’s new Defender for DevOps capabilities to empower security managers and leaders to unify DevOps security posture visibility across multiple pipelines and help strengthen security from development to runtime.
Azure DevOps supports many different authentication mechanisms, including basic authentication, personal access tokens (PATs), SSH, and Azure Active Directory access tokens. These mechanisms are not created equal from a security perspective, especially when it comes to the potential for credential theft. For example, unintended leakage of credentials like PATs can let malicious actors into Azure DevOps organizations where they can gain access to critical assets like source code, pivot toward supply chain attacks, or even pivot toward compromising production infrastructure.
Over the past couple of years, we’ve introduced many new security-relevant configuration settings. While we’ve always followed “secure by default” principles and enabled these settings for newly created organizations/projects, we’ve not enabled them for existing organizations/projects to avoid disruptive impacts.
For example, we’ve introduced several improvements to the security posture of Azure Pipelines, including restricting the default scope of the pipeline identity from the entire organization down to the project, restricting the resources that can be accessed by a pipeline to those which it explicitly references, and more. Collectively, these changes prevent malicious actors from using pipelines to move laterally within an organization and gain access to resources to which they personally lack permissions. These settings are all enabled by default in new organizations and projects. But because enabling them in existing organizations and projects can cause existing pipelines to start failing, we’ve left it to administrators to explicitly enable them.
We’ve listened to feedback from security-focused customers and Azure DevOps administrators, and we’ll be focusing on making it easier for them to:
We’ll start by ensuring that security-relevant settings all have clear recommendations in the product. Longer term we’ll focus on enabling non-disruptive rollout of configuration hardening through audit modes, allow lists, and auto-mitigations. For the Pipelines settings discussed above, these changes will allow administrators to understand which settings are not in their recommended states and which pipelines will start failing when the settings are updated. Further, they will allow pipeline owners to easily understand and apply the changes required to keep their pipelines working.
E-commerce Development Company in Junagadh