Enhanced security management
With this update, you now have the option to enable or disable Advanced Security for your entire project or organization. You can also automatically enable Advanced Security for any newly created repositories or projects.
In Azure Pipelines, we added a centralized control to improve the security of pull requests built from forked GitHub repositories.
Check out the release notes to learn more about these features.
General
Project and organization-level enablement for Advanced Security
Estimated committer count during Advanced Security enablement
Azure Pipelines
Azure Repos
Azure Artifacts
General
Project and organization-level enablement for Advanced Security
You can now enable or disable Advanced Security for your entire project or organization. In conjunction with the new addition of displaying committer count prior to enablement, selecting "Enable all" at the project or organization-level will provide you with an estimate of how many new active committers you may be billed for. You can also opt to automatically enable Advanced Security for any newly created repositories or projects under your respective project or organization. Any repositories enabled through this setting will have secret repository scanning and push protection active.
Project-level enablement:
Organization-level enablement:
Estimated committer count during Advanced Security enablement
As a part of your Advanced Security onboarding experience, you can now see an estimate of how many active committers may have been added as a result of enabling Advanced Security for a particular repository, project, or organization. This count is an approximation and you may see slight discrepancies between the provided estimate and what is reported for billing after enablement. This estimate can also be obtained via API with additional documentation explaining this process coming soon.
Azure Pipelines
Retry a stage when approvals and checks time out
When approvals and checks time out, the stage they belong to is skipped. Stages that have a dependency on the skipped stage are also skipped.
Now you can retry a stage when approvals and checks time-out. Previously, this was possible only when an approval timed out.
Administrator role for all Environments
Environments in YAML pipelines represent a compute resource to which you deploy your application, for example an AKS cluster or a set of VMs. They provide you with security controls and traceability for your deployments.
Managing environments can be quite challenging. This is because, when an environment is created, the person creating it automatically becomes the sole administrator. For example, if you want to manage the approvals and checks of all environments in a centralized fashion, you had to ask every environment administrator to add a specific user or group as administrator, and then use REST API to configure the checks. This approach is tedious, error-prone, and doesn't scale when new environments are added.
With this sprint, we added an Administrator role at the environments-hub level. This brings environments up to par with service connections or agent pools. To assign the Administrator role to a user or group, you need to already be an environments-hub administrator or organization-owner.
A user with this Administrator role can administer permissions, manage, view and use any environment. This includes opening up environments to all pipelines.
When you grant a user Administrator role at environments-hub level, they become administrators for all existing environments and for any future environments.
Centralized control for building PRs from forked GitHub repos
If you build public repositories from GitHub, you must consider your stance on fork builds. Forks are especially dangerous since they come from outside your organization.
You can improve the security of pipelines that build GitHub public repositories by reviewing our recommendations on how to Build GitHub repositories and Repository protection. Unfortunately, managing numerous pipelines and ensuring their adherence to best practices can require a substantial amount of effort.
To enhance the security of your pipelines, we added an organization-level control for defining how pipelines build PRs from forked GitHub repos. The new setting is named Limit building pull requests from forked GitHub repositories and works at organization and project level.
The organization-level setting restricts the settings projects can have, and the project-level setting restricts the settings pipelines can have.
Let's look at how the toggle works at organization level. The new control is off by default, so no settings are universally enforced.
When you turn on the toggle, you can choose to disable building PRs from forked GitHub repos. This means, no pipeline will run when such a PR is created.
When you choose the Securely build pull requests from forked repositories option, all pipelines, organization-wide, cannot make secrets available to builds of PRs from forked repositories, cannot make these builds have the same permissions as normal builds, and must be triggered by a PR comment. Projects can still decide to not allow pipelines to build such PRs.
When you choose the Customize option, you can define how to restrict pipeline settings. For example, you can ensure that all pipelines require a comment in order to build a PR from a forked GitHub repo, when the PR belongs to non-team members and non-contributors. But, you can choose to allow them to make secrets available to such builds. Projects can decide to not allow pipelines to build such PRs, or to build them securely, or have even more restrictive settings that what is specified at the organization level.
Azure Repos
New "Branch policy" preventing users to approve their own changes
To improve the control around what changes user approves and match stricter regulatory/compliance requirements, we do provide an option to prevent user approving his own changes unless explicitly allowed.
User with ability to manage the branch policies can now switch newly added option "Require at least one approval on every iteration" under the "When new changes are pushed". When this option is selected, then at least one approval vote for the last source branch change is required. The user's approval is not counted against any previous unapproved iteration pushed by that user. As a result, additional approval on the last iteration is required to be done by another user.
Following image shows pull request created by user A and additional 4 commits (iterations) made to that pull request by users B, C, A again and C. After the second iteration (commit done by user B) was done, user C approved that. At that time, it implied approval of first commit of user A (when the pull request was created) and the newly introduced policy will succeed. After the fifth iteration (last commit of user C), the approval was done by user A. This implied approval for earlier commit done by user C, but was not implying approval for the second commit done by user A in the fourth iteration. To make the newly introduced policy to succeed, the unapproved iteration four must be approved either by approval from user B, C or any other user who has not made any change to the pull request.
Azure Artifacts
Introducing Azure Artifacts support for Cargo Crates (public preview)
We're excited to announce that Azure Artifacts now offer native support for Cargo crates. This support includes feature parity with respect to our existing protocols, in addition to crates.io being available as an upstream source. Rust developers and teams can now consume, publish, manage, and share their Cargo crates seamlessly, all while using Azure's robust infrastructure and staying in the familiar Azure DevOps environment.
No sign-up is needed for the preview; you can get started by navigating to your Azure DevOps project, selecting Artifacts, and following the instructions to connect your Rust project to your Azure Artifacts feed.
Next steps
Note
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.
You can also get advice and your questions answered by the community on Stack Overflow.
Thanks,
Silviu Andrica
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for