GitHub Advanced Security for Azure DevOps public preview starts now!
In October of last year we announced that GitHub Advanced Security was coming to Azure DevOps, starting with a private preview in November. Since then, we’ve been working hard on the product and incorporating feedback from our private preview customers. Today, we are excited to announce that GitHub Advanced Security for Azure DevOps is available to everyone in a public preview! Sign up for the preview, and we’ll do our best to get your Azure DevOps organization(s) enabled as soon as possible.
As a reminder – GitHub Advanced Security for Azure DevOps brings the same industry leading developer security capabilities as GitHub Advanced Security to Azure DevOps, integrated directly into Azure Repos and Azure Pipelines. This includes the same secret scanning, dependency scanning, and CodeQL code scanning capabilities available within GitHub Enterprise.
Secret Scanning: Exposed credentials are implicated in over 50% of security breaches. GitHub Advanced Security for Azure DevOps can not only help you find secrets that have already been exposed in Azure Repos, but also help you prevent new exposures by blocking any pushes to Azure Repos that contain secrets. All with a single click.
We’ve used secret scanning push protection inside Microsoft for years, and it’s been a huge help reducing developer toil: if you only catch a secret once it’s already made it into Azure Repos, the only way to really be safe is to rotate that secret everywhere it’s used and then permanently revoke it. Depending on how widely the secret is used, this could be days of effort and stress – if you miss rotating the secret in just one of the places it’s used, you could cause a live site outage! On the other hand, if you block the secret exposure at push time, before it’s persisted in Azure Repos, it’s a five-minute job to clean up your commit and repush. So much easier!
Dependency Scanning: Open-source supply chain attacks are on the rise. GitHub Advanced Security for Azure DevOps identifies open-source package vulnerabilities present in your code – through both direct and transitive dependencies – and provides straightforward guidance from the GitHub Advisory Database on how to upgrade your packages to mitigate the vulnerabilities.
Issues detected in each of these categories are presented in a repository-scoped Advanced Security experience using the Azure DevOps design language. All that is to say – it will all feel native to Azure DevOps and totally natural to Azure DevOps customers!
Pricing: GitHub Advanced Security for Azure DevOps has the same pricing as GitHub Advanced Security – $49 per active committer per month. Billing is done through Azure, so you can use the same Azure subscriptions and payment vehicles used for the rest of your Azure DevOps bill. And because billing is metered, the costs will be pro-rated based on the repositories you enable and the length of time they are enabled. There’s no purchase commitment necessary at all – you can scale your usage up, or down, or off at any time just by enabling or disabling the protections on whichever repos you select in the Azure DevOps configuration settings.
We are incredibly excited to be reaching this milestone and to be making these powerful capabilities available to all Azure DevOps customers. They will go a long way toward helping you secure your DevOps infrastructure, your code, and your production environments.
To learn more about GitHub Advanced Security for Azure DevOps, see https://aka.ms/advanced-security. To learn more about other upcoming Azure DevOps investments in security and beyond, see https://aka.ms/AzureDevOpsRoadmap.
This is great news, looking forward to enhancing security in our Azure Devops repos as well. For orgs that are using both Azure Devops and Github, how will this work from a licensing point of view? Is the Azure Devops license separate from the GHAS native license which implies that the same user will be double licensed?
Our intent is to not double-charge for individuals who are committing to both GHAS- and GHAzDO-enabled repos. However, we don’t currently have a high-confidence way to determine this programmatically. If you have people in your org who are committing to both, please contact your GH/MSFT account exec and we’ll work something out for you.
Thanks for sharing! It’s definitely a nice addition to the Azure DevOps tool set. I do wonder about the security regarding the manipulation of this setting, is anything known about what groups will be able to manipulate it?
By default it takes Project Collection Admin (PCA) permissions to enable/disable GHAzDO. However, PCAs can delegate to other groups (such as Project Admins) if they so choose.