消除高级安全性中的依赖项扫描警报
高级安全性中的依赖项扫描可检测源代码中使用的开放源代码组件,并识别是否存在任何关联的漏洞。 从开源组件中发现的任何漏洞都将被标记为警报。 通过此更新,可以在高级安全中消除依赖项扫描警报,这些警报被认为是误报或可接受的风险。
在 Azure Repos 中,我们更改了默认行为,以在创建新分支时删除“编辑策略”权限。
请查看发行说明,了解有关这些功能的详细信息。
适用于 Azure DevOps 的 GitHub Advanced Security
Azure Boards
Azure Pipelines
Azure Repos
常规
Advanced Security 中依赖项扫描警报的警报消除
现在可以消除任何认为误报或可接受的风险的依赖项扫描警报。 这些是当前可以使用的高级安全中机密扫描和代码扫描警报的相同消除选项。
请注意,可能需要使用依赖项扫描任务重新运行检测管道,并确保你拥有 Advanced Security: dismiss alerts
权限才能消除这些警报。
若要了解有关警报消除的详细信息,请参阅 “消除依赖项扫描警报”。
Azure Boards
将链接复制到工作项
我们进行了一些改进,以便从 Azure Boards 中的多个区域复制工作项 URL。 更轻松地获取指向特定工作项的直接链接。
复制链接 已添加到工作项窗体、积压工作和任务积压工作上的上下文菜单。
注意
此功能仅适用于 新板中心 预览版。
Azure Pipelines
Kubernetes 任务现在支持 kubelogin
我们已更新 KubernetesManifest@1、 HelmDeploy@0、 Kubernetes@1 和 AzureFunctionOnKubernetes@1 任务以支持 kubelogin。 通过此操作,能够以配置了 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=00aa00aa-bb11-cc22-dd33-44ee44ee44ee&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 检查无法正常工作,需要修复它。 以前,必须删除此类检查,以防止它们错误地阻止部署。 修复检查后,必须重新添加并正确配置它,确保设置所有必需的标头或查询参数正确。 这是繁琐的。
现在,只需禁用检查即可。 禁用的检查不会在后续检查套件评估中运行。
修复错误检查后,只需启用它即可。
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.DisplayName
displayName
cron 计划属性的新预定义系统变量来实现此实现。
用于控制经典管道创建的新切换
去年,我们启动了管道配置设置,以 禁用经典生成和发布管道的创建。
为了响应你的反馈,我们已将初始切换拆分为两个:一个用于经典 生成 管道,一个用于经典 发布 管道、部署组和任务组。
如果组织已 Disable creation of classic build and release pipelines
打开开关,则这两个新开关都处于打开模式。 如果原始切换处于关闭状态,则两个新切换都处于关闭状态。
Azure Repos
删除分支创建者的“编辑策略”权限
以前,创建新分支时,我们被授予编辑该分支上的策略的权限。 通过此更新,我们将更改默认行为,不再授予此权限(即使存储库启用了“权限管理”设置)。
你需要具备通过安全权限继承或组成员身份显式授予的“编辑策略”权限(手动或通过 REST API)。
后续步骤
注意
这些功能将在未来两到三周内推出。
前往 Azure DevOps 并了解一下。
如何提供反馈
我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获得社区的建议和问题的答案。
此致
Silviu Andrica