Improvements to secret scanning capabilities and New Board Hub on by default

We're excited to announce we're rolling out a security overview, a single pane of glass view for your Advanced Security alerts and enablement, and we've also improved our secret scanning capabilities by adding more partner patterns in GitHub Advanced Security! This will significantly increase the detection abilities of our secret scanning feature, providing a more secure environment for your projects.

With this update, we're close to making New Boards Hub your default experience! It will introduce an updated design, better performance, and enhanced accessibility. In addition, we're previewing two new features within Boards: AB# Links on GitHub pull requests and a more reliable GitHub repository search, removing the risk of timeouts.

Check out the release notes for details.

GitHub Advanced Security for Azure DevOps

Azure Boards

Azure Pipelines

GitHub Advanced Security for Azure DevOps

Security overview risk and coverage views

You can now see an organization-wide view of your repositories and their Advanced Security alerts and Advanced Security enablement status of all repositories in your organization.

The security overview feature for Advanced Security can be found by navigating to Organization settings > Security overview. For more information, see Security overview on GitHub Advanced Security for Azure DevOps.

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 many high confidence patterns for new token types. These new patterns include a large number of Azure resource providers, and other SaaS providers through the GitHub Advanced Security secret scanning partner program.

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.

Secret Scanning now detects non-provider patterns

Secret scanning now detects many non-provider patterns, including:

  • HTTP authentication headers
  • MongoDB connection strings
  • MySQL/Postgres/SQL Server connection strings
  • OpenSSH private keys
  • RSA private keys


The detection of non-provider patterns is currently in preview and subject to change.

Detection of these patterns is enabled for all GitHub Advanced Security enabled repositories in Azure DevOps. Resulting secrets appear in a new, separate filter on the secret scanning alert list called "Confidence.”

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

Azure Boards

New Boards Hub on by default

If you’ve been keeping up with the progress of New Boards Hub, you’re probably aware that the preview has been active for quite some time now. In fact, we officially announced the preview of New Boards Hub a little over two years ago.

Today, we’re happy to announce the final stage of our journey. We're beginning the process of making New Boards Hub the default experience for all of our customers. This happens in two waves, with the first starting in the middle of April. The rollout process for each wave spans several weeks, as we gradually roll out to a different set of customers every other day.

For more information, please see our latest blog post here.

After several weeks in preview, we're excited to announce an enhanced experience for linking work items to GitHub. Search and select the desired repository and drill down to find and link to the specific pull request or commit. No more need for multiple window changes and copy/paste (although you still have that option).

Gif to demo Add link improvements.


This feature is only available in the New Boards Hub preview.

As part of our ongoing enhancements to the Azure Boards + GitHub integration, we're previewing a feature that improves experience with AB# links. With this update, your AB# links will now appear directly in the Development section of the GitHub pull request. This means you can view the linked work items without the need to navigate through description or comments, resulting in easier access to those AB# links.

Screenshots of AB# links.

These links will only be available when you use AB# in the pull the request description. They won't show up if you link directly from the pull request from the work item. Removing the AB# link from the description will also remove it from the Development control.

If you're interested in participating in the preview, please reach out to us directly via email. Make sure to include your GitHub organization name ({organization name}).

Connect to GitHub repository search improvements (preview)

Previously, connecting an Azure DevOps project to a GitHub organization with thousands of repositories was challenging. Customers with that many GitHub repositories can encounter timeout errors or long wait times. Today we're announcing a preview that unblocks large GitHub organizations. You can now search and select across thousands of repositories without the risk of timeout issues.

We're happy to enable to this feature upon request. If you're interested, please send us your Azure DevOps organization name ({organization}).

Azure Pipelines

Edit queue build configuration permission

To help you improve the security posture of your pipelines, we're adding a new pipeline permission named Edit queue build configuration that controls who can define the values of variables set at queue time and of free-text runtime parameters.

Screenshot of permissions.

Variables set at queue time and parameters allow you to write configurable YAML pipelines. Unfortunately, they also introduce the possibility of user input to be executed. The new permission mitigates this risk.

Users who have only Queue build permission are able to queue builds and edit the values of runtime parameters that have a predefined set of values. That is, they're able to choose values for parameters that are of type boolean, number or they have the values property set.

If a parameter can contain free text, for example, is of type object, then only those users who have the Edit queue build configuration permission are able to set it.

Consider a pipeline with the following parameters defined:

- name: Configuration
  type: string
  - release
  - debug
  default: debug
- name: UseNewDeploymentMethod
  type: boolean
  default: false
- name: AzureSKU
  type: object
    WUS1: Standard D2lds v5
    WUS2: Standard D2lds v5
    WUS3: Standard D2lds v5

If a user queueing a run has only the Queue build permission. When they queue the pipeline, they'll be able to only specify the values of the Configuration and UseNewDeploymentMethod parameters. They won't be able to specify the value for the AzureSKU parameter.

Screenshot of run pipeline.

Changing variables marked as settable at queue time also requires the Edit queue build configuration permission. Otherwise, one can't change the variable value.

Screenshot of variables.

To make sure the new permission doesn't interfere with your day-to-day workloads, everyone who has Queue build permission receives the Edit queue build configuration permission. Afterward, you can remove this permission as needed.

TFX validates whether a task is using an End of Life Node runner

Task authors use TFX to publish extensions. TFX has been updated to perform validations on other Node runner versions.

Extensions that contain tasks using a Node runner version that is end of life (EOL) (up to and including Node 16) will see this warning:

Task < TaskName > is dependent on a task runner that is end-of-life and are removed in the future. Authors should review Node upgrade guidance:

Next steps


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

Head over to Azure DevOps and take a look.

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.


Dan Hellem