消除高级安全性中的依赖项扫描警报

  • 项目

高级安全性中的依赖项扫描可检测源代码中使用的开放源代码组件，并识别是否存在任何关联的漏洞。 从开源组件中发现的任何漏洞都将被标记为警报。 通过此更新，可以在高级安全中消除依赖项扫描警报，这些警报被认为是误报或可接受的风险。

在 Azure Repos 中，我们更改了默认行为，以在创建新分支时删除“编辑策略”权限。

请查看发行说明，了解有关这些功能的详细信息。

适用于 Azure DevOps 的 GitHub Advanced Security

Azure Boards

Azure Pipelines

Azure Repos

常规

Advanced Security 中依赖项扫描警报的警报消除

现在可以消除任何认为误报或可接受的风险的依赖项扫描警报。 这些是当前可以使用的高级安全中机密扫描和代码扫描警报的相同消除选项。

Dismiss a dependency scanning alert

请注意，可能需要使用依赖项扫描任务重新运行检测管道，并确保你拥有 Advanced Security: dismiss alerts 权限才能消除这些警报。

若要了解有关警报消除的详细信息，请参阅 “消除依赖项扫描警报”。

Azure Boards

我们进行了一些改进，以便从 Azure Boards 中的多个区域复制工作项 URL。 更轻松地获取指向特定工作项的直接链接。

Image for copy link context menu item on backlog

复制链接 已添加到工作项窗体、积压工作和任务积压工作上的上下文菜单。

注意

此功能仅适用于 新板中心 预览版。

Azure Pipelines

Kubernetes 任务现在支持 kubelogin

我们更新了支持 kubelogin 的KuberentesManifest@1、HelmDeploy@0、Kubernetes@1和AzureFunctionOnKubernetes@1任务。 通过此操作，能够以配置了 Azure Active Directory 集成的 Azure Kubernetes 服务 (AKS) 为目标。

未在托管映像上预安装 Kubelogin。 若要确保上述提及任务使用 kubelogin，请在依赖于它的任务之前插入KubeloginInstaller@0任务来安装它：

 - task: KubeloginInstaller@0

 - task: HelmDeploy@0
   # arguments do not need to be modified to use kubelogin

对 审批 REST API 的改进

审批通过让你能够手动查看部署到生产环境的部署来提高 YAML 管道的安全性。 我们更新了审批查询 REST API，使其更强大。 现在，你：

  • 无需指定 approvalId列表。 所有参数现在都是可选的。
  • 可以指定一个列表 userId来检索这些用户挂起的审批列表。 目前，REST API 返回将用户显式分配为审批者的审批列表。
  • 可以指定要 state 返回的审批，例如 pending。

下面是一个示例： GET https://dev.azure.com/fabrikamfiber/fabrikam-chat/_apis/pipelines/approvals?api-version=7.1-preview.1&userId=47acd774-9773-6c31-bbb6-5a0585695d19&state=pending 返回

{
    "count": 2,
    "value":
    [
        {
            "id": "87436c03-69a3-42c7-b5c2-6abfe049ee4c",
            "steps": [],
            "status": "pending",
            "createdOn": "2023-06-27T13:58:07.417Z",
            "lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers": [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/87436c03-69a3-42c7-b5c2-6abfe049ee4c"
                }
            }
        },
        {
            "id": "2549baca-104c-4a6f-b05f-bdc4065a53b7",
            "steps": [],
            "status": "pending",
            "createdOn": "2023-06-27T13:58:07.417Z",
            "lastModifiedOn": "2023-06-27T13:58:07.4164237Z",
            "executionOrder": "anyOrder",
            "minRequiredApprovers": 1,
            "blockedApprovers": [],
            "_links":
            {
                "self":
                {
                    "href": "https://dev.azure.com/fabrikamfiber/fabricam-chat/_apis/pipelines/approvals/2549baca-104c-4a6f-b05f-bdc4065a53b7"
                }
            }
        }
    ]
}

禁用检查

我们使调试检查不那么繁琐。 有时，调用 Azure 函数或调用 REST API 检查无法正常工作，需要修复它。 以前，必须删除此类检查，以防止它们错误地阻止部署。 修复检查后，必须重新添加并正确配置它，确保设置所有必需的标头或查询参数正确。 这是繁琐的。

现在，只需禁用检查。 禁用检查不会在后续检查套件评估中运行。

Disable a check image.

修复错误检查后，只需启用它即可。

Enable a check image.

汇报 YAML cron 计划

在 YAML 管道中，可以使用 YAML 属性定义计划的触发器cron。

我们更新了 batch 属性的工作原理。 简而言之，如果将 batch 设置为 true，则当另一个计划的管道运行正在进行时，cron 计划将不会运行。 这与管道存储库的版本无关。

下表介绍了 always 和 batch 的交互方式。

始终 Batch 行为
false false 仅当上次成功的计划管道运行发生更改时，管道才会运行
false true 仅当上次成功的计划管道运行发生更改且没有正在进行的计划管道运行时，管道才会运行
true false 根据 cron 计划运行管道
true true 根据 cron 计划运行管道

例如，假设 always: false 和 batch: true。 假设有一个 cron 计划，指定管道应每隔 5 分钟运行一次。 假设有一个新提交。 在 5 分钟内，管道将启动其计划运行。 假设管道运行需要 30 分钟才能完成。 在这 30 分钟内，无论提交数如何，都不会进行计划运行。 下一个计划运行仅在 当前计划运行完成之后 才会发生。

YAML 管道可能包含多个 cron 计划，并且你可能希望管道基于运行 cron 计划运行的不同阶段/作业。 例如，你有一个夜间生成和每周生成，并希望在每周生成期间，管道收集更多统计信息。

我们可以通过引入一个名为包含 Build.CronSchedule.DisplayNamedisplayName cron 计划属性的新预定义系统变量来实现此实现。

用于控制经典管道创建的新切换

去年，我们启动了管道配置设置，以 禁用经典生成和发布管道的创建。

为了响应你的反馈，我们已将初始切换拆分为两个：一个用于经典 生成 管道，一个用于经典 发布 管道、部署组和任务组。

Disable creation

如果组织已 Disable creation of classic build and release pipelines 打开开关，则这两个新开关都处于打开模式。 如果原始切换处于关闭状态，则两个新切换都处于关闭状态。

Azure Repos

删除分支创建者的“编辑策略”权限

以前，创建新分支时，我们被授予编辑该分支上的策略的权限。 通过此更新，我们将更改默认行为，不再授予此权限（即使存储库启用了“权限管理”设置）。

Permission management image.

你需要具备通过安全权限继承或组成员身份显式授予的“编辑策略”权限（手动或通过 REST API）。

后续步骤

注意

这些功能将在未来两到三周内推出。

前往 Azure DevOps 并了解一下。

转到 Azure DevOps

如何提供反馈

我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。

Make a suggestion

你还可以在 Stack Overflow 上获得社区的建议和问题的答案。

此致

Silviu Andrica