고급 보안에서 종속성 검사 경고 해제
Advanced Security의 종속성 검사는 소스 코드에 사용되는 오픈 소스 구성 요소를 검색하고 관련된 취약성이 있는지 식별합니다. 오픈 소스 구성 요소에서 발견된 취약성은 경고로 플래그가 지정됩니다. 이 업데이트를 사용하면 가양성 또는 허용 가능한 위험이라고 생각되는 고급 보안에서 종속성 검사 경고를 해제할 수 있습니다.
Azure Repos에서 새 분기를 만들 때 "정책 편집" 권한을 제거하도록 기본 동작을 변경했습니다.
이러한 기능에 대해 자세히 알아보려면 릴리스 정보를 확인하세요.
Azure DevOps용 GitHub Advanced Security
Azure Boards
Azure Pipelines
- Kubernetes 작업은 이제 kubelogin을 지원합니다.
- YAML cron 일정에 업데이트
- 검사 사용 안 함
- 승인 REST API 개선 사항
- 클래식 파이프라인 만들기를 제어하는 새 토글
Azure Repos
일반
고급 보안에서 종속성 검사 경고에 대한 경고 해제
이제 가양성 또는 허용 가능한 위험으로 판단되는 모든 종속성 검사 경고를 해제할 수 있습니다. 다음은 현재 사용할 수 있는 고급 보안의 비밀 검색 및 코드 검색 경고에 대한 동일한 해제 옵션입니다.
종속성 검사 작업을 사용하여 검색 파이프라인을 다시 실행하고 이러한 경고를 해제하기 위해 권한이 있는지 확인해야 Advanced Security: dismiss alerts 할 수 있습니다.
경고 해제에 대한 자세한 내용은 종속성 검사 경고 해제를 참조 하세요.
Azure Boards
작업 항목에 링크 복사
Azure Boards의 여러 영역에서 작업 항목 URL을 복사하도록 약간 개선했습니다. 특정 작업 항목에 대한 직접 링크를 더 쉽게 가져올 수 있도록 합니다.
복사 링크 가 작업 항목 양식, 백로그 및 작업 백로그의 상황에 맞는 메뉴에 추가되었습니다.
참고 항목
이 기능은 New Boards Hubs 미리 보기에서만 사용할 수 있습니다.
Azure Pipelines
Kubernetes 작업은 이제 kubelogin을 지원합니다.
kubelogin을 지원하기 위해 KuberentesManifest@1, HelmDeploy@0, Kubernetes@1 및 AzureFunctionOnKubernetes@1 작업을 업데이트했습니다. 이렇게 하면 Azure Active Directory 통합으로 구성된 AKS(Azure Kubernetes Service)를 대상으로 지정할 수 있습니다.
Kubelogin은 호스트된 이미지에 미리 설치되어 있지 않습니다. 위의 멘션 작업에서 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 호출 검사 제대로 작동하지 않아 수정해야 합니다. 이전에는 이러한 검사 삭제하여 배포를 잘못 차단하지 않도록 해야 했습니다. 검사 수정한 후에는 다시 추가하고 올바르게 구성하여 필요한 모든 헤더가 설정되거나 쿼리 매개 변수가 올바른지 확인해야 했습니다. 이것은 지루합니다.
이제 검사 사용하지 않도록 설정할 수 있습니다. 비활성화된 검사 후속 검사 제품군 평가에서 실행되지 않습니다.
잘못된 검사 수정한 후에는 사용하도록 설정할 수 있습니다.
YAML cron 일정에 업데이트
YAML 파이프라인에서는 YAML 속성을 사용하여 예약된 트리거를 정의할 cron 수 있습니다.
batch 속성의 작동 방식을 업데이트했습니다. 간단히 말해서 batch을 true로 설정하면 예정된 다른 파이프라인 실행이 진행 중인 경우 cron 일정이 실행되지 않습니다. 파이프라인 리포지토리의 버전과 관계가 없습니다.
다음 표에서는 방법 및 batch 상호 작용에 대해 always 설명합니다.
| 항상 | Batch | 동작 |
|---|---|---|
false |
false |
마지막으로 성공한 예약된 파이프라인 실행과 관련하여 변경 내용이 있는 경우에만 파이프라인이 실행됩니다. |
false |
true |
마지막으로 성공한 예약된 파이프라인 실행과 관련하여 변경 내용이 있고 진행 중인 예약된 파이프라인 실행이 없는 경우에만 파이프라인이 실행됩니다. |
true |
false |
cron 일정에 따라 파이프라인 실행 |
true |
true |
cron 일정에 따라 파이프라인 실행 |
예를 들어 가정 always: false 및 batch: true. 파이프라인이 5분마다 실행되도록 지정하는 cron 일정이 있다고 가정합니다. 새 커밋이 있다고 상상해 보십시오. 5분 이내에 파이프라인은 예약된 실행을 시작합니다. 파이프라인 실행을 완료하는 데 30분이 걸린다는 것을 상상해 보세요. 이 30분 이내에는 커밋 수에 관계없이 예약된 실행이 발생하지 않습니다. 다음 예약된 실행은 현재 예약된 실행이 완료된 후에만 발생합니다.
YAML 파이프라인에는 여러 cron 일정이 포함될 수 있으며, cron 일정이 실행되는 단계에 따라 파이프라인이 다른 단계/작업을 실행하도록 할 수 있습니다. 예를 들어 야간 빌드 및 주간 빌드가 있으며, 주간 빌드 중에 파이프라인이 더 많은 통계를 수집하기를 바랍니다.
cron 일정의 속성을 포함하는 명명 Build.CronSchedule.DisplayName 된 새 미리 정의된 시스템 변수를 displayName 도입하여 이를 가능하게 합니다.
클래식 파이프라인 만들기를 제어하는 새 토글
작년에는 클래식 빌드 및 릴리스 파이프라인 만들기를 사용하지 않도록 설정하는 파이프라인 구성 설정을 시작했습니다.
피드백에 따라 초기 토글을 클래식 빌드 파이프라인용과 클래식 릴리스 파이프라인, 배포 그룹 및 작업 그룹용으로 분할했습니다.
조직에 토글이 Disable creation of classic build and release pipelines 켜진 경우 두 새 토글이 모두 설정됩니다. 원래 토글이 꺼져 있으면 두 새 토글이 모두 꺼집니다.
Azure Repos
분기 작성자에 대한 "정책 편집" 권한 제거
이전에는 새 분기를 만들 때 해당 분기에 대한 정책을 편집할 수 있는 권한이 부여되었습니다. 이 업데이트에서는 리포지토리에 대해 "권한 관리" 설정이 켜져 있어도 이 권한을 부여하지 않도록 기본 동작을 변경합니다.
사용자는 보안 권한 상속 또는 그룹 멤버 자격을 통해 명시적으로(수동으로 또는 REST API를 통해) 부여받은 "정책 편집" 권한이 필요합니다.
다음 단계
참고 항목
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
Azure DevOps로 이동하여 살펴보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
실비우안드리카
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기