Enhanced AB# link tracking in GitHub pull requests

  • Article

With this update, AB# links now appear directly in the Development section of GitHub pull requests, as long as they are included in the pull request description. This enhancement simplifies access to linked work items through the Azure Boards and GitHub integration.

We’re also excited to introduce enhanced monitoring tools, offering greater visibility into your repository’s health and helping you maintain its performance more efficiently!

Check out the release notes for details.

GitHub Advanced Security for Azure DevOps

Azure Boards:

Azure Repos

Azure Pipelines

Azure Test Plans:

GitHub Advanced Security for Azure DevOps

Pull request branches now visible in Advanced Security branch picker

Pull request branches were previously hidden in the branch picker, even though scanning on pull request branches was possible. Now, these branches are visible in the Advanced Security branch picker and can be searched.

Screenshot of Pull request branches.

Automatic updates for default branch changes in Advanced Security

In the past, the Advanced Security repository tab did not automatically update when the default branch changed, requiring manual selection of the new branch in the branch picker. Now, the tab automatically detects and displays alerts for the newly designated default branch upon visiting the page.

Additionally, the Security Overview updates to reflect default branch changes, although there may be a slight delay before the updated alert results are processed.

Generic third-party SARIF support for Advanced Security

You can now upload results from your third-party scanning tool to show in the Advanced Security code scanning tab.

Using a scanning tool that publishes a SARIF file to the $(Agent.TempDirectory)/.advsec directory, conforms to the SARIF 2.1 standard, and runs the AdvancedSecurity-Publish@1 after the task will upload results to the code scanning tab.

Note

The file path associated with a result in the SARIF file must be accessible to the AdvancedSecurity-Publish@1 task running in the build agent.

Alert rule IDs now integrated into result fingerprints

Previously, third-party tool results with the same fingerprint, hash, tool, and rule name were grouped into one alert, even if they had different rule IDs.

With this update, rule IDs are now included in the fingerprint, creating separate alerts for results with different rule IDs, even if other data points are the same. Existing alerts will be updated and split accordingly.

Pull request annotations feature in (preview)

As outlined in the Advanced Security roadmap item, Pull-request annotations, you will now receive in-line annotations on pull requests that use a pipeline linked to your build validation policy with dependency or code scanning tasks.

No opt-in is required—just create a build validation policy for the relevant branches.

Clicking Show more details in the annotation will take you to the alert detail view.

Screenshot of In-line annotations.

Expanded set of Secret Scanning detections

We're expanding the set of partner patterns that can be detected with Secret Scanning. This expansion brings in several high confidence patterns for new token types.

For more information on the types of partner patterns that GitHub Advanced Security Secret Scanning detects, see Secret scanning alerts for GitHub Advanced Security for Azure DevOps.

Azure Boards

As part of our ongoing enhancements to the Azure Boards + GitHub integration, we’re excited to introduce a new feature that streamlines how AB# links are displayed. With this update, AB# links now appear directly in the Development section of GitHub pull requests, making it easier to access linked work items without searching through descriptions or comments.

Screenshot of GitHub pull requests.

These links will only appear when AB# is included in the pull request description. If you link directly from a work item, they won’t be displayed in the Development section. Additionally, removing the AB# link from the description removes it from the Development control.

REST API support for connecting GitHub repositories

We're introducing new REST API endpoints that enable you to automate the addition and removal of GitHub repositories in your Azure DevOps Projects. Additionally, we increased the repository limit per connection from 500 to 2,000 when using these endpoints.

These endpoints include:

We have also provided sample code to help you get started.

Permanently delete attachments

In some cases, simply removing an attachment from a work item may not fully resolve security risks, especially if the file is flagged as malicious. Shared links to the attachment could still be accessible across other work items, comments, or external channels. To address this, we added a feature that allows users with "Permanently delete work items" permissions to permanently remove attachments.

SScreenshot of permanently delete work item attachments.

This action can be performed from the Attachments tab on the work item form, under a new section called "Deleted Attachments". This section is visible only to users with the necessary permissions to permanently delete work items.

Once an attachment is permanently deleted, all associated links return a "File attachment does not exist" error.

Note

This feature is only available in the New Boards Hub.

Azure Repos

New "Health and usage" panel in repo file hub

As Git repositories grow, they accumulate commits, blobs, and other data, which can increase the load on Azure DevOps infrastructure, impacting performance and user experience. Maintaining a healthy repository is key to ensuring consistent performance and reliability.

To support this, we now monitor several factors like repository size, commit frequency, contents, and structure. If your repository begins to strain the infrastructure, you may receive a notification with recommendations for corrective action. By managing your repository’s health, you can prevent disruptions and ensure smooth operations.

To check your repository’s health, go to Azure Repos, > Files and choose “Health and usage” from the ellipsis menu to access the Repository health and usage panel.

Screenshot of Health and usage.

Azure Pipelines

Azure Pipeline agent v4 runs on .NET 8

The Azure Pipeline agent v3 currently uses .NET 6, but with the end-of-life for .NET 6 approaching, we're upgrading the agent to .NET 8. This update will be rolled out over the coming weeks.

If you're using self-hosted agents on an operating system that isn't supported by .NET 8, your agent won’t be upgraded to v4. Instead, pipelines running on unsupported operating systems display warnings in the pipeline logs. You can use the QueryAgentPoolsForCompatibleOS.ps1 script to identify any pipeline agents running on outdated operating systems proactively.

The following operating system versions won't be supported by the updated v4 agent:

  • Alpine Linux 3.13 - 3.16
  • Debian 10
  • Fedora 36 - 38
  • macOS 10 & 11
  • openSUSE 15.0 - 15.4
  • Oracle Linux 7
  • Red Hat Enterprise Linux 7
  • SUSE Enterprise Linux 12
  • Ubuntu, 16.04, 18.04
  • Windows 7, 8 & 10 up to 21H2

Preview mode for shell tasks arguments validation

Shell tasks such as Bash@3, BatchScript@1, CmdLine@2 and PowerShell@2 can be protected from command injection by enabling shell tasks arguments validation in organization or project settings.

Enabling shell tasks arguments validation can break existing scripts as input is rejected by input validation. For example, some characters are considered a command separator and rejected when this setting is enabled.

To make this transition smoother, we added a preview mode. With preview mode enabled, you receive warnings in your pipeline and audit logs, giving you visibility into potential issues without interrupting your tasks or workflows.

Go to Organization Settings > Pipelines > Settings > Task restrictions > Audit On:

Screenshot of general to enable auditing.

Revised naming convention for Azure service connections and App registrations

Previously, service connections were named using the format:<azure devops org>-<azure devops project>-<azure subscription id>. This made it challenging to correlate app registrations with corresponding service connections targeting the same Azure subscription. To improve clarity, app registration names now include the service connection name, following this format: <azure devops org>-<azure devops project>-<service connection name> for easier identification.

Azure Test Plans

Seamless build Pipeline integration for test case execution

We’ve simplified the test case execution process by seamlessly integrating build pipeline configurations. Build definitions and IDs set at the test plan level now automatically propagate to the Web Runner, eliminating the need for manual configuration each time. This improvement saves time and enhances efficiency, allowing you to focus on more critical tasks.

Gif to demo Pipeline Integration for Test Case Execution.

Test and feedback extension in Manifest V3 (Edge release)

We’ve been gradually releasing this upgrade in Chrome, and now we’re expanding the rollout to Edge.

This update transitions our implementation from Manifest V2 to V3, in line with Google's deprecation schedule for Manifest V2. While the core features of the extension remain unchanged, the update enhances both security and performance.

For more details, check out our recent blog post about this update. Test & Feedback Extension in Manifest V3

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.

Make a suggestion

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

Thanks,

Dan Hellem