Edit

Share via

GitHub Advanced Security and Managed identity and service principal support for Azure DevOps are now generally available

  • Article

We are excited to announce that GitHub Advanced Security and Managed identity and service principal support for Azure DevOps are now generally available!

On GitHub Advanced Security, we've also improved code scanning to include all user-provided inputs in the CodeQL Initialize task. In addition, we expanded CodeQL support to include Swift.

In Boards, we are releasing Team Automation Rules in private preview. Now, you can configure each backlog level to automate the opening and closing/resolving of work items based on the state(s) of their children. Check out the release notes if you are interested in enrolling in the private preview.

Head over to the feature list below to learn move about these features.

General

GitHub Advanced Security for Azure DevOps

Azure Boards

Azure Pipelines

General

Managed identity and service principal support for Azure DevOps now in general availability (GA)

Support for Microsoft Entra ID managed identities and service principals in Azure DevOps has now reached general availability (GA).

Today, many application integration scenarios rely on Personal Access Tokens (PATs) to integrate with Azure DevOps. While simple to use, PATs can easily be leaked, potentially enabling malicious actors to authenticate as powerful users. To prevent unwanted access, PATs often also require time-consuming maintenance through regular credential rotations.

You can now enable applications to instead use Managed Identities and Service Principals to integrate with Azure DevOps through REST APIs and client libraries. This highly requested feature offers Azure DevOps customers a more secure alternative to PATs. Managed Identities offer the ability for applications running on Azure resources to obtain Azure AD tokens without needing to manage any credentials at all.

Managed Identities and Service Principals can be setup in Azure DevOps and given permissions to specific assets (projects, repos, pipelines), just like regular users. This allows applications that use Managed Identities or Service Principals to connect to Azure DevOps and perform actions on behalf of themselves, instead of on behalf of a user, as PAT do. Teams can now better manage their services collectively, instead of relying on any one individual to provide a token for authentication. Learn more about the GA release in our public blog post announcement and our feature documentation.

New Azure DevOps scopes available for Microsoft Identity OAuth delegated flow apps

We have added new Azure DevOps scopes for delegated OAuth apps on the Microsoft Identity platform, also colloquially known as Microsoft Entra ID OAuth apps. These new scopes will enable app developers to announce specifically which permissions they are hoping to request from the user in order to perform app duties. This highly requested feature allows app developers to request from their users solely the permissions they need for their app.

Previously, user_impersonation was the only scope available for app developers to choose from. This scope gives the app full access to all Azure DevOps APIs, which means it will be able to do anything that the user is able to do across all organizations that the user belongs to. Now with more granular scopes available, you can rest easy that apps can only request and access solely those APIs that the requested scopes have granted them permission to access.

Learn more about these new scopes in our public blog post announcement and feature documentation.

GitHub Advanced Security for Azure DevOps

Changes to Code Scanning (CodeQL) user input task and variables

All user-provided inputs are now specified in the CodeQL Initialize task, which is responsible for configuring the CodeQL analysis environment used for code analysis with CodeQL `AdvancedSecurity-Codeql-Init@1``. See the configure GitHub Advanced Security for Azure DevOps features documentation for more information on configuring GitHub Advanced Security for Azure DevOps.

In addition, user inputs take precedence over any values set by variables. For instance, if you establish the language variable as advancedsecurity.codeql.language: Java and subsequently, during the CodeQL initialization phase, you specify the language as an input with Language: cpp, the input cpp will override the variable Java for the language. Please ensure that your inputs are configured accurately.

Publish task is no longer required for Setting up code Scanning

Previously, when configuring code scanning, you were required to include the publish task (AdvancedSecurity-Publish@1) in either the YAML pipeline or classic pipeline. With this update, we've eliminated the need for the publish task, and the results are now directly posted to the advanced security service within the analyze task (AdvancedSecurity-Codeql-Analyze@1).

Below are the require task for code scanning.

Screenshot of required code scanning tasks.

For more information, please refer to the set up code scanning documentation.

CodeQL code scanning now supports Swift

We're expanding our support for CodeQL code scanning to include Swift! This means that developers working on Swift libraries and applications for Apple platforms can now take advantage of our top-notch code security analysis. Our current capabilities include the detection of issues such as path injection, risky web view fetches, various cryptographic misuses, and other forms of unsafe handling or processing of unfiltered user data.

Swift is now part of our roster of supported programming languages, which includes C/C++, Java/Kotlin, JavaScript/TypeScript, Python, Ruby, C#, and Go. Altogether, these languages enable us to perform nearly 400 comprehensive checks on your code, all while maintaining a low rate of false positives and ensuring high precision.

See the configure GitHub Advanced Security for Azure DevOps features documentation for more information on configuring GitHub Advanced Security for Azure DevOps for your repositories.

Azure Boards

Team Automation Rules (private preview)

Important

As of 11/9/2023, we are not taking any new organizations into the private preview. We have had great feedback with just a couple of minor bugs to resolve. We are working on those bugs and will be releasing the feature to everyone in the next few sprints.

You can now configure each backlog level to automate the opening and closing/resolving of work items based on the state(s) of their children. There are two main scenarios we are attempting to solve.

  1. When a single child item is activated, then activate the parent.

  2. When all child items are closed, then close the parent (or resolve it).

To enable these settings, you click on the backlog level configuration for your team. Then go to the Automation > Rules tab to see the two different rules you can apply to your backlog. Each backlog level (requirements, features, epics) can be configured for how your team wants to work.

Screenshots of Team Settings.

For example, when any child Task is set to Active, make the parent User Story active. Then, when all Tasks are completed, set the User Story to Closed.

Gif to demo Team automation rules.

If you are interested in enrolling in the private preview, please send us an email with your organization name (dev.azure.com/{organization name}). Please understand that we will be limiting the number of organizations into the preview. Our hope is to get a few organizations to provide feedback and then release to everyone within 2-3 sprints.

The features was prioritized based on this Developer Community suggestion ticket.

Note

This feature will only be available with the New Boards Hubs preview.

Azure Pipelines

Pipeline logs now contain resource utilization

Azure pipeline logs can now capture resource utilization metrics such as memory, CPU usage and available disk space. The logs also include resources used by the pipeline agent and child processes including tasks run in a job.

Screenshot of logs including resources used by the pipeline.

If you suspect your pipeline job may run into resource constraints, enable verbose logs to have resource utilization information injected into pipeline logs. This works on any agent, independent from hosting model.

Azure Pipelines agent now supports Alpine Linux

The Pipeline agent v3.227 now supports Alpine Linux versions 3.13 and above. Alpine Linux is a popular for container (base) image. You can find the agent on the releases page. Alpine Linux versions of the agent have a prefix vsts-agent-linux-musl e.g. vsts-agent-linux-musl-x64-3.227.1.tar.gz.

Next steps

Note

These features will roll out over the next two to three weeks.

Head over to Azure DevOps and take a look.

Go to Azure DevOps

How to provide feedback

We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.

Screenshot Make a suggestion.

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Rajesh Ramamurthy