- 제한사항
- 파이프라인 요구 사항
- 여러 파이프라인을 사용하는 병합 요청
- 병합 요청 승인 정책 편집기
- 병합 요청 승인 정책 스키마
- 병합 요청 승인 정책 스키마
scan_finding규칙 유형license_findingrule typeany_merge_requestrule typerequire_approvalaction type-
send_bot_message작업 유형 approval_settingsfallback_behavior- 보안 정책 범위
- 보안 병합 요청 승인 정책 프로젝트의 예시
- 병합 요청 승인 정책 편집기 예시
- merge request 승인 정책 approvals 이해하기
- 문제 해결
병합 요청 승인 정책
- GitLab 15.6에서 그룹 수준의 스캔 결과 정책이 도입되었습니다.
- 스캔 결과 정책 기능은 GitLab 16.9에서 병합 요청 승인 정책으로 이름이 변경되었습니다.
프로젝트 수준의 설정 및 검토 규칙을 강제하는 데 병합 요청 승인 정책을 사용하세요. 예를 들어, 보안 스캔 작업의 결과에 따라 필요에 따라 승인을 요구하는 보안 승인 정책이 있습니다. 병합 요청 승인 정책은 CI 스캔 작업이 완전히 실행된 후에 평가되며 취약점 및 라이선스 유형 정책은 완료된 파이프라인에 발표된 작업 artifact 보고서를 기반으로 평가됩니다.
다음 비디오에서 이전의 스캔 결과 정책이었던 GitLab 병합 요청 승인 정책을 개요합니다:
제한사항
- 보호된 대상 브랜치에서만 병합 요청 승인 정책을 강제할 수 있습니다.
- 각 정책에 최대 5개의 규칙을 할당할 수 있습니다.
- 각 보안 정책 프로젝트에 최대 5개의 병합 요청 승인 정책을 할당할 수 있습니다.
- 그룹 또는 하위 그룹에 대한 생성된 정책은 그룹 내의 모든 병합 요청에 적용되기까지 시간이 걸릴 수 있습니다.
- 병합 요청 승인 정책은 작업 artifact 보고서에서 생성된 스캔 결과의 무결성이나 신뢰성을 확인하지 않습니다.
- 병합 요청 승인 정책은 규칙에 따라 평가됩니다. 기본적으로 규칙이 잘못되거나 평가할 수 없는 경우 승인이 필요합니다. 이 동작은
fallback_behaviorfield를 사용하여 변경할 수 있습니다.
파이프라인 요구 사항
병합 요청 승인 정책은 파이프라인 결과에 따라 강제됩니다. 병합 요청 승인 정책을 구현할 때 다음을 고려하세요:
- 병합 요청 승인 정책은 완료된 파이프라인 작업을 평가하며, 수동 작업은 무시합니다. 수동 작업이 실행되면, 정책은 병합 요청의 작업을 다시평가합니다.
- 보안 스캐너 결과를 평가하는 병합 요청 승인 정책의 경우 모든 지정된 스캐너의 결과를 가져야합니다. 그렇지 않으면 취약점이 도입되는 위험을 최소화하기 위해 승인이 강제됩니다.
- 파이프라인은 소스 및 대상 브랜치에 대해 모든 활성화된 스캐너에 대한 artifact를 생성해야합니다. 그렇지 않으면 비교할 기준이 없어서 정책을 평가할 수 없습니다. 이 요구 사항을 강제하는 데 사용하십시오.
- 정책 평가는 성공적이고 완료된 병합 베이스 파이프라인에 의존합니다. 병합 베이스 파이프라인이 건너 뛰어진 경우 병합 베이스 파이프라인이 차단됩니다.
- 정책에서 지정된 보안 스캐너는 해당 정책이 강제된 프로젝트에서 구성 및 활성화되어야합니다. 그렇지 않으면 병합 요청 승인 정책을 평가할 수 없으며 해당 승인이 필요합니다.
여러 파이프라인을 사용하는 병합 요청
- GitLab 16.2에서 flag랑 함께 소개되었습니다. 기본값은 꺼져 있습니다.
- GitLab 16.3에서 일반적으로 사용 가능해짐.
multi_pipeline_scan_result_policiesfeature flag 삭제됨.- GitLab 16.11에서 부모-자식 파이프라인 지원이 구현 되었습니다. 기본값은 꺼져 있습니다.
- GitLab 17.0에서 GitLab.com에서 활성화되었습니다.
- GitLab 17.1에서 일반적으로 사용 가능해짐.
approval_policy_parent_child_pipelinefeature flag 삭제됨.
프로젝트는 여러 파이프라인 유형을 구성할 수 있습니다. 단일 커밋은 여러 파이프라인을 시작할 수 있으며, 각각에 보안 스캔이 포함될 수 있습니다.
- GitLab 16.3 이상에서는 병합 요청 승인 정책을 강제하기위해 최신 커밋에 대한 소스 및 대상 브랜치의 모든 완료된 파이프라인 결과가 평가되고 사용됩니다. 요청 DAST 파이프라인은 고려되지 않습니다.
- GitLab 16.2 및 이전 버전에서는 병합 요청 승인 정책을 강제할 때 최신 완료된 파이프라인 결과 만 고려되었습니다.
프로젝트가 병합 요청 파이프라인을 사용하는 경우, 보안 스캔 작업이 파이프라인에 포함되어 있기 때문에 latest 보안 템플릿를 사용해야합니다.
자세한 내용은 병합 요청 파이프라인에 보안 스캔 도구 사용를 참조하십시오.
병합 요청 승인 정책 편집기
- GitLab 15.6에서 기본적으로 활성화되었습니다.
정책이 완료되면 편집기 하단의 병합 요청으로 구성을 선택하여 저장합니다. 이렇게 하면 프로젝트에서 구성된 보안 정책 프로젝트의 병합 요청으로 리디렉션됩니다. 보안 정책 프로젝트와 연결되지 않았을 경우 GitLab은 해당 프로젝트를 생성합니다. 기존 정책은 편집기 인터페이스 하단의 정책 삭제를 선택하여 제거할 수 있습니다.
대부분의 정책 변경은 병합 요청이 병합될 때 즉시 적용됩니다. 병합 요청을 통해 직접 커밋되지 않는 변경 사항은 정책 변경이 적용되기까지 최대 10분이 소요됩니다.
정책 편집기는 YAML 모드와 규칙 모드를 지원합니다.
병합 요청 승인 정책 스키마
병합 요청 승인 정책을 포함하는 YAML 파일은 approval_policy 키 아래에 중첩된 병합 요청 승인 정책 스키마와 일치하는 객체 배열로 구성됩니다. approval_policy 키 아래에 최대 다섯 개의 정책을 구성할 수 있습니다.
참고:
병합 요청 승인 정책은 scan_result_policy 키 아래에 정의되었습니다. GitLab 17.0까지 정책은 두 키 모두에서 정의할 수 있습니다. GitLab 17.0부터는 approval_policy 키만 지원됩니다.
새로운 정책을 저장할 때 GitLab은 해당 내용을 이 JSON 스키마에 대해 유효성을 검사합니다. JSON 스키마를 읽는 방법에 익숙하지 않은 경우 다음 섹션 및 테이블에서 다른 방법을 제공합니다.
| 필드 | 유형 | 필수 | 가능한 값 | 설명 |
|---|---|---|---|---|
approval_policy
|
array of Merge Request Approval Policy
| true | 병합 요청 승인 정책의 목록 (최대 5개). |
병합 요청 승인 정책 스키마
approval_settings필드는 GitLab 16.4에서scan_result_policies_block_unprotecting_branches,scan_result_any_merge_request, 또는scan_result_policies_block_force_push라는 플래그와 함께 도입되었습니다. 자세한 내용은 아래의approval_settings섹션을 참조하세요.
| 필드 | 유형 | 필수 | 가능한 값 | 설명 |
|---|---|---|---|---|
name
| string
| true | 정책의 이름. 최대 255자까지 입력할 수 있습니다. | |
description
| string
| false | 정책에 대한 설명. | |
enabled
| boolean
| true |
true, false
| 정책을 활성화(true) 또는 비활성화(false)하는 플래그.
|
rules
|
array of rules
| true | 정책이 적용되는 규칙의 목록. | |
actions
|
array of actions
| false | 정책이 시행하는 조치의 목록. | |
approval_settings
| object
| false | 정책이 재정의하는 프로젝트 설정들. | |
fallback_behavior
| object
| false | 무효 또는 시행 불가능한 규칙에 영향을 주는 설정들. |
scan_finding 규칙 유형
- 병합 요청 승인 정책 필드
vulnerability_attributes는 GitLab 16.2에서enforce_vulnerability_attributes_rules라는 플래그와 함께 도입되었습니다. GitLab 16.3에서 일반 사용 가능하며, 플래그가 제거되었습니다.- 병합 요청 승인 정책 필드
vulnerability_age는 GitLab 16.2에서 도입되었습니다.branch_exceptions필드는 GitLab 16.3에서security_policies_branch_exceptions라는 플래그와 함께 도입되었습니다. GitLab 16.5에서 일반 사용 가능하며, 플래그가 제거되었습니다.vulnerability_states옵션newly_detected는 GitLab 17.0에서 제거되었으며, 대신new_needs_triage및new_dismissed옵션이 추가되었습니다.
해당 규칙은 보안 스캔 결과를 기반으로 정의된 조치를 시행합니다.
| 필드 | 유형 | 필수 | 가능한 값 | 설명 |
|---|---|---|---|---|
type
| string
| true | scan_finding
| 규칙의 유형. |
branches
|
array of string
|
branch_type 필드가 존재하지 않으면 true
|
[] 또는 브랜치의 이름
| 적용 대상은 보호된 대상 브랜치에만 해당됩니다. 빈 배열인 []은 모든 보호된 대상 브랜치에 규칙을 적용합니다. branch_type 필드와 함께 사용할 수 없습니다.
|
branch_type
| string
|
branches 필드가 존재하지 않으면 true
|
default 또는 protected
| 주어진 정책이 적용되는 보호된 브랜치의 유형. branches 필드와 함께 사용할 수 없습니다. 기본 브랜치는 반드시 protected여야 합니다.
|
branch_exceptions
|
array of string
| false | 브랜치의 이름들 | 해당 규칙에서 제외할 브랜치입니다. |
scanners
|
array of string
| true |
sast, secret_detection, dependency_scanning, container_scanning, dast, coverage_fuzzing, api_fuzzing
| 해당 규칙에서 고려할 보안 스캐너들입니다. sast는 SAST 및 SAST IaC 스캐너의 결과를 포함합니다.
|
vulnerabilities_allowed
| integer
| true | 0보다 크거나 같은 정수 | 규칙이 고려되기 전에 허용되는 취약점의 개수입니다. |
severity_levels
|
array of string
| true |
info, unknown, low, medium, high, critical
| 해당 규칙이 고려할 심각도 수준입니다. |
vulnerability_states
|
array of string
| true |
[] 또는 detected, confirmed, resolved, dismissed, new_needs_triage, new_dismissed
| 모든 취약점은 두 가지 카테고리로 나뉩니다: 신규 감지된 취약점 - 병합 요청 브랜치에서 식별된 취약점이지만 현재 MR 대상 브랜치에는 없는 취약점. 이 정책 옵션은 규칙이 평가되기 전에 파이프라인이 완료되어야 하므로 새로 감지된 취약점인지 여부를 알 수 있습니다. 새로운 감지된 취약점이나 아닌지를 옵션을 통해 확인합니다. 새로운 감지된 취약점이 아니라면 파이프라인 및 필요한 보안 스캔이 완료될 때까지 병합 요청이 차단됩니다. new_needs_triage 옵션은 상태를 고려합니다.• 감지됨 new_dismissed 옵션은 상태를 고려합니다.• (폐기됨을 고려함 기존 취약점 - 이 정책 옵션들은 즉시 평가되며 프로젝트의 기본 브랜치에서 이전에 감지된 취약점만을 고려합니다. • 감지됨 - 정책은 감지된 상태의 취약점을 찾습니다.• 확인됨 - 정책은 확인된 상태의 취약점을 찾습니다.• 폐기됨 - 정책은 폐기된 상태의 취약점을 찾습니다.• 해결됨 - 정책은 해결된 상태의 취약점을 찾습니다.빈 배열인 []은 ['new_needs_triage', 'new_dismissed']와 동일한 상태를 다룹니다.
|
vulnerability_attributes
| object
| false | {false_positive: boolean, fix_available: boolean}
| 모든 취약점 결과를 기본적으로 고려합니다. 하지만 속성에 대한 필터를 적용하여 취약점 결과를 고려할 수 있습니다: • 수정 가능한 경우 ( fix_available: true)• 수정 가능하지 않은 경우 ( fix_available: false)• 잘못된 경우 ( false_positive: true)• 잘못된 경우가 아닌 경우 ( false_positive: false)• 또는 ( fix_available: true, false_positive: false)와 같은 결합도 가능합니다.
|
vulnerability_age
| object
| false | N/A | 나이에 따른 이전 취약점 결과를 필터링합니다. 취약점의 나이는 프로젝트에서 탐지된 지 날짜를 기준으로 합니다. 기준은 operator, value, interval입니다.- operator 기준은 나이 비교에 사용되는 경우(더 오래된 것은 greater_than, 더 새로운 것은 less_than)를 지정합니다.- value 기준은 취약점의 나이를 나타내는 숫자 값을 지정합니다.- interval 기준은 취약점의 나이의 단위를 지정합니다: day, week, month, year입니다.예: operator: greater_than, value: 30, interval: day.
|
license_finding rule type
- 소개된 날짜: GitLab 15.9에 라이선스 스캐닝 정책이라는 플래그와 함께 소개되었습니다.
- 일반적으로 사용 가능한 기능: GitLab 15.11에서.
license_scanning_policies기능 플래그가 제거되었습니다.branch_exceptions필드는 GitLab 16.3에 라이선스 스캐닝 정책이라는 플래그와 함께 소개되었습니다. 기본적으로 활성화됩니다. GitLab 16.5에서 일반적으로 사용 가능한 기능. 기능 플래그가 제거되었습니다.
이 규칙은 라이선스 발견을 기반으로 정의된 조치를 시행합니다.
| 필드 | 타입 | 필요여부 | 가능한 값 | 설명 |
|———————-|———————|——————————————–|——————————|————-|
| type | string | true | license_finding | 규칙의 유형 |
| branches | array of string | true if branch_type field does not exist | [] or the branch’s name | 해당 규정이 적용되는 보호된 대상 브랜치. 빈 배열[]은 모든 보호된 대상 브랜치에 규칙을 적용합니다. ‘branch_type’ 필드를 사용할 수 없습니다. |
| branch_type | string | branches 필드가 존재하지 않으면 true | default 또는 protected | 주어진 정책이 적용되는 보호된 브랜치 유형. ‘branch 필드를 사용할 수 없습니다. 기본 브랜치도 보호되어야 합니다. |
| branch_exceptions | array of string | false | 브랜치 이름 | 이 규칙에서 제외할 브랜치 |
| match_on_inclusion_license | boolean | true | true, false | 규칙이 license_types’에 나열된 라이선스의 포함 또는 제외와 일치하는지 여부 |
| license_types | array of string | true | 라이센스 유형 | SPDX 라이선스 이름을 예를 들면 Affero General Public License v1.0 또는 MIT License. |
| license_states | array of string | true | newly_detected, detected | 새로 발견된 라이선스와/또는 이전에 발견된 라이선스와 일치하는지 여부. newly_detected 상태는 새로운 패키지가 도입되거나 기존 패키지에 새로운 라이선스가 감지될 때 승인을 유발합니다. |
any_merge_request rule type
branch_exceptions필드는 GitLab 16.3에서 라이선스 스캐닝 정책이라는 플래그와 함께 소개되었습니다. 기본적으로 활성화됩니다. 일반적으로 사용 가능한 기능: GitLab 16.5. 기능 플래그가 제거되었습니다.any_merge_request규칙 유형은 GitLab 16.4에서 소개되었습니다. 기본적으로 활성화됩니다. GitLab 16.6에서 일반적으로 사용 가능한 기능. 기능 플래그가 제거되었습니다.
이 규칙은 커밋 서명을 기반으로 모든 병합 요청에 대한 정의된 조치를 시행합니다.
| 필드 | 타입 | 필요여부 | 가능한 값 | 설명 |
|———————|———————|——————————————–|—————————|————-|
| type | string | true | any_merge_request | 규칙의 유형 |
| branches | array of string | branch_type 필드가 존재하지 않으면 true | [] 또는 브랜치 이름 | 해당 규정이 적용되는 보호된 대상 브랜치. 빈 배열 []은 모든 보호된 대상 브랜치에 규칙을 적용합니다. ‘branch_type’ 필드를 사용할 수 없습니다. |
| branch_type | string | branches 필드가 존재하지 않으면 true | default 또는 protected | 주어진 정책이 적용되는 보호된 브랜치 유형. ‘branch 필드를 사용할 수 없습니다. 기본 브랜치도 보호되어야 합니다. |
| branch_exceptions | array of string | false | 브랜치 이름 | 이 규칙에서 제외할 브랜치 |
| commits | string | true | any, unsigned` | 규칙이 모든 커밋에 대해 일치하는지 또는 병합 요청에서 감지된 서명되지 않은 커밋만 일치하는지 여부 |
require_approval action type
이 작업은 정의된 정책에서 적어도 하나의 규칙이 충족될 때 승인 규칙이 필요하도록 설정합니다.
| 필드 | 타입 | 필요여부 | 가능한 값 | 설명 |
|---|---|---|---|---|
type
| string
| true | require_approval
| 작업의 유형 |
approvals_required
| integer
| true | 0 이상의 정수 | 필요한 MR 승인 수 |
user_approvers
|
array of string
| false | 하나 이상의 사용자명 | 승인자로서 고려할 사용자. 승인자는 프로젝트에 액세스해야 합니다. |
user_approvers_ids
|
array of integer
| false | 하나 이상의 사용자 ID | 승인자의 ID. 승인자는 프로젝트에 액세스해야 합니다. |
group_approvers
|
array of string
| false | 하나 이상의 그룹 경로 | 승인 그룹. 직접적으로 그룹 멤버쉽에 있는 사용자가 승인자로서 적합합니다. |
group_approvers_ids
|
array of integer
| false | 하나 이상의 그룹 ID | 승인자 그룹의 ID. 직접적으로 그룹 멤버쉽에 있는 사용자가 승인자로서 적합합니다. |
role_approvers
|
array of string
| false | 하나 이상의 역할 (예: owner, maintainer)
| 승인자로서 적합한 역할 |
send_bot_message 작업 유형
send_bot_message작업 유형은 GitLab 16.11에서 프로젝트를 대상으로 도입되었습니다.approval_policy_disable_bot_comment라는 플래그와 함께 사용됩니다. 기본적으로 비활성화됩니다. (자세한 정보)- GitLab 17.0에서
self-managed와 GitLab Dedicated에서 활성화되었습니다. (활성화 정보)- GitLab 17.3에서 일반 사용 가능해졌습니다. 기능 플래그
approval_policy_disable_bot_comment가 제거되었습니다.send_bot_message작업 유형은 GitLab 17.2에서 그룹을 대상으로하는데 도입되었으며,approval_policy_disable_bot_comment_group이라는 플래그와 함께 사용됩니다. 기본적으로 비활성화됩니다. (자세한 정보)- GitLab 17.2에서
self-managed와 GitLab Dedicated에서 활성화되었습니다.- GitLab 17.3에서 일반 사용 가능해졌습니다. 기능 플래그
approval_policy_disable_bot_comment_group가 제거되었습니다.
이 작업은 정책 위반을 감지할 때 병합 요청에서 봇 메시지의 구성을 활성화합니다.
작업이 지정되지 않은 경우, 봇 메시지는 기본적으로 활성화됩니다. 여러 정책이 정의된 경우, 적어도 그 정책 중 하나가 send_bot_message 작업이 활성화되어 있는 경우 봇 메시지가 전송됩니다.
| 필드 | 유형 | 필수 여부 | 가능한 값 | 설명 |
|---|---|---|---|---|
type
| string
| true | send_bot_message
| 작업의 유형입니다. |
enabled
| boolean
| true |
true, false
| 정책 위반을 감지할 때 봇 메시지를 생성해야하는지 여부입니다. 기본값: true
|
봇 메시지 예시
approval_settings
block_group_branch_modification필드는 GitLab 16.8에서 도입되었으며,scan_result_policy_block_group_branch_modification이라는 플래그와 함께 사용됩니다. 기본적으로 비활성화됩니다. (자세한 정보)block_unprotecting_branches필드는 GitLab 16.4에서 도입되었으며,scan_result_policy_settings이라는 플래그와 함께 사용됩니다. 기본적으로 비활성화됩니다.scan_result_policy_settings기능 플래그는 16.4에서scan_result_policies_block_unprotecting_branches기능 플래그로 대체되었습니다.block_unprotecting_branches필드는 GitLab 16.7에서block_branch_modification필드로 대체되었습니다.- 위의 필드는 GitLab 16.7에서 GitLab.com 및
self-managed에서 활성화되었습니다.prevent_approval_by_author,prevent_approval_by_commit_author,remove_approvals_with_new_commit및require_password_to_approve필드는 GitLab 16.4에서 도입되었으며,scan_result_any_merge_request이라는 플래그와 함께 사용됩니다. 기본적으로 비활성화됩니다.- 위의 필드는 GitLab 16.6에서 GitLab.com 및
self-managed에서 활성화되었습니다.- 기능 플래그
scan_result_any_merge_request가 GitLab 16.8에서 제거되었습니다.prevent_pushing_and_force_pushing필드는 GitLab 16.4에서 도입되었으며,scan_result_policies_block_force_push이라는 플래그와 함께 사용됩니다. 기본적으로 비활성화됩니다.- 위의 필드는 GitLab 16.6에서 GitLab.com 및
self-managed에서 활성화되었습니다.- 기능 플래그
scan_result_policies_block_force_push가 GitLab 16.8에서 제거되었습니다.
플래그:
self-managed GitLab에서는 기본적으로 block_branch_modification 필드가 사용 가능합니다. 기능을 숨기려면 관리자가 scan_result_policies_block_unprotecting_branches라는 플래그를 비활성화할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 있습니다.
정책에서 설정된 값은 프로젝트의 설정을 덮어씁니다.
| 필드 | 유형 | 필수 여부 | 가능한 값 | 적용 가능한 규칙 유형 | 설명 |
|---|---|---|---|---|---|
block_branch_modification
| boolean
| false |
true, false
| 모든 | 활성화되면, 사용자가 보호된 브랜치 목록에서 브랜치를 제거하거나, 보호된 브랜치를 삭제하거나, 보호된 브랜치에 포함된 기본 브랜치를 변경하는 것을 방지합니다. 이를 통해 사용자가 취약한 코드를 병합하기 위해 브랜치의 보호 상태를 제거하지 못하도록합니다. branches, branch_type 및 policy_scope에 따라 감지된 취약점 여부와 관계없이 적용됩니다.
|
block_group_branch_modification
|
boolean 또는 object
| false |
true, false, { enabled: boolean, exceptions: [string] }
| 모든 | 활성화되면, 정책이 적용되는 모든 그룹에 대해 그룹 수준의 보호된 브랜치를 제거하는 것을 방지합니다. block_branch_modification이 true인 경우, 암시적으로 true로 기본 설정됩니다. branches, branch_type 및 policy_scope에 따라 감지된 취약점 여부와 관계없이 적용됩니다.
|
prevent_approval_by_author
| boolean
| false |
true, false
| 임의의 병합 요청
| 활성화되면, 병합 요청 작성자는 자신의 MR를 승인할 수 없습니다. 이를 통해 코드 작성자가 취약점을 도입하고 코드를 승인하여 병합할 수 없도록합니다. |
prevent_approval_by_commit_author
| boolean
| false |
true, false
| 임의의 병합 요청
| 활성화되면, MR에 코드 기여자가 있는 사용자는 승인을 받을 자격이 없습니다. 이를 통해 코드 커밋러가 취약점을 도입하고 코드를 승인하여 병합할 수 없도록합니다. |
remove_approvals_with_new_commit
| boolean
| false |
true, false
| 임의의 병합 요청
| 활성화되면, MR가 병합에 필요한 모든 승인을받았지만 새 커밋이 추가되면 새 승인이 필요합니다. 이를 통해 새로운 취약점을 도입할 수있는 새 커밋이 도입되지 못하도록합니다. |
require_password_to_approve
| boolean
| false |
true, false
| 임의의 병합 요청
| 활성화되면 승인시 암호 확인이 필요합니다. 암호 확인으로 추가적인 보안 계층이 추가됩니다. |
prevent_pushing_and_force_pushing
| boolean
| false |
true, false
| 모든 | 활성화되면, 사용자가 보호된 브랜치로 푸시 및 강제 푸시하는 것을 방지합니다. 이를 통해 사용자가 병합 요청 프로세스를 우회하여 취약한 코드를 브랜치에 추가하는 것을 방지합니다. |
fallback_behavior
-
fallback_behavior필드는 GitLab 17.0에서 도입되었습니다.security_scan_result_policies_unblock_fail_open_approval_rules라는 플래그와 함께 기능 플래그로 명명되었습니다. 기본적으로 비활성화됩니다. -
fallback_behavior필드는 GitLab 17.0에서 GitLab.com, Self-Managed, 및 GitLab Dedicated에서 활성화되었습니다.
플래그:
자체 관리형 GitLab에서 fallback_behavior 필드가 기본적으로 제공됩니다. 기능을 숨기려면 관리자가 보안 검사 결과 정책을 차단하고 열린 승인 규칙이라는 기능 플래그를 비활성화할 수 있습니다. GitLab.com 및 GitLab Dedicated에서 이 기능을 사용할 수 있습니다.
| 필드 | 유형 | 필수 여부 | 가능한 값 | 설명 |
|---|---|---|---|---|
fail
| string
| false |
open 혹은 closed
|
closed (기본): 정책의 부적합하거나 강제할 수 없는 규칙은 승인이 필요합니다. open: 정책의 부적합하거나 강제할 수 없는 규칙은 승인이 필요하지 않습니다.
|
보안 정책 범위
-
GitLab 16.7에서 도입되었습니다.
security_policies_policy_scope이라는 기능 플래그와 함께 기본적으로 활성화됩니다. -
GitLab 16.11에서 일반적으로 사용 가능하게 되었습니다. 기능 플래그
security_policies_policy_scope가 제거되었습니다. - 그룹별로 스코핑이 GitLab 17.4에서 도입되었습니다.
보안 정책 강제화는 먼저 정책을 적용하려는 그룹, 하위 그룹 또는 프로젝트와 정책을 포함하는 보안 정책 프로젝트 간의 연결을 설정하는 것에 달려있습니다. 예를 들어, 정책을 그룹에 연결하는 경우, 그룹 소유자가 보안 정책 프로젝트에 대한 링크를 만들어야 합니다. 그런 다음 보안 정책 프로젝트에 있는 모든 정책이 그룹의 모든 프로젝트에서 상속됩니다.
보안 정책의 범위는 다음과 같이 세분화할 수 있습니다:
- 규정 준수 프레임워크 라벨이 포함되어 있는 프로젝트만 포함.
- 선택한 프로젝트를 강제화 대상으로 지정하거나 배제.
- 선택한 그룹을 포함.
projects객체와 함께 선택적으로 사용하여 선택한 프로젝트를 배제할 수 있습니다.
정책 범위 스키마
| 필드 | 유형 | 필수 여부 | 가능한 값 | 설명 |
|---|---|---|---|---|
policy_scope
| object
| false |
compliance_frameworks, projects, groups
| 규정 준수 프레임워크 라벨, 프로젝트 또는 정의한 그룹을 기반으로 정책을 범위 지정합니다. |
policy_scope 범위 유형
| 필드 | 유형 | 가능한 값 | 설명 |
|---|---|---|---|
compliance_frameworks
| array
| 강제화 범위 내 규정 준수 프레임워크 ID 목록으로, id 키를 사용한 객체 배열입니다.
| |
projects
| object
|
including, excluding
|
excluding: 또는 including:을 사용하고, ID를 사용한 프로젝트 ID 목록으로, id 키를 사용한 객체 배열입니다.
|
groups
| object
| including
|
including:을 사용하고, ID를 사용한 그룹 ID 목록으로, id 키를 사용한 객체 배열입니다.
|
규칙에 따른 policy.yml 예시
---
approval_policy:
- name: critical vulnerability CS approvals
description: container scanning을 위한 심각한 보안 취약점 CS 승인
enabled: true
rules:
- type: scan_finding
branches:
- main
scanners:
- container_scanning
vulnerabilities_allowed: 1
severity_levels:
- critical
vulnerability_states: []
actions:
- type: require_approval
approvals_required: 1
user_approvers:
- adalberto.dare
policy_scope:
compliance_frameworks:
- id: 2
- id: 11
projects:
including:
- id: 24
- id: 27
보안 병합 요청 승인 정책 프로젝트의 예시
이 예시는 보안 정책 프로젝트에 저장된 .gitlab/security-policies/policy.yml 파일에서 사용할 수 있습니다:
---
approval_policy:
- name: critical vulnerability CS approvals
description: critical severity level only for container scanning
enabled: true
rules:
- type: scan_finding
branches:
- main
scanners:
- container_scanning
vulnerabilities_allowed: 0
severity_levels:
- critical
vulnerability_states: []
vulnerability_attributes:
false_positive: true
fix_available: true
actions:
- type: require_approval
approvals_required: 1
user_approvers:
- adalberto.dare
- name: secondary CS approvals
description: secondary only for container scanning
enabled: true
rules:
- type: scan_finding
branches:
- main
scanners:
- container_scanning
vulnerabilities_allowed: 1
severity_levels:
- low
- unknown
vulnerability_states:
- detected
vulnerability_age:
operator: greater_than
value: 30
interval: day
actions:
- type: require_approval
approvals_required: 1
role_approvers:
- owner
이 예시에서:
- 컨테이너 스캐닝으로 식별된 새로운
critical취약점이 포함된 모든 MR에는alberto.dare의 승인이 필요합니다. - 30일 이상된 기존의
low또는unknown취약점이 하나 이상 포함된 모든 MR에는 Owner 역할을 가진 프로젝트 멤버 중 한 명의 승인이 필요합니다.
병합 요청 승인 정책 편집기 예시
이 예시는 병합 요청 승인 정책 편집기의 YAML 모드에서 사용할 수 있습니다. 이는 이전 예시의 단일 객체에 대응합니다:
type: approval_policy
name: critical vulnerability CS approvals
description: critical severity level only for container scanning
enabled: true
rules:
- type: scan_finding
branches:
- main
scanners:
- container_scanning
vulnerabilities_allowed: 1
severity_levels:
- critical
vulnerability_states: []
actions:
- type: require_approval
approvals_required: 1
user_approvers:
- adalberto.dare
merge request 승인 정책 approvals 이해하기
- 16.8 버전에서
scan_finding의 브랜치 비교 논리가 변경되었습니다(변경됨), 기본적으로 비활성화된scan_result_policy_merge_base_pipeline플래그와 함께.- 16.9 버전에서 일반적으로 이용 가능합니다. 피처 플래그
scan_result_policy_merge_base_pipeline이 제거되었습니다.
병합 요청 승인 정책 비교 범위
- 병합 요청에 대한 승인이 필요한 시점을 결정하기 위해 각 지원되는 파이프라인 소스로부터 완료된 파이프라인을 소스 브랜치와 대상 브랜치(예:
feature/main) 각각에 대해 비교합니다. 이는 스캔 결과를 가장 포괄적으로 평가합니다. - 소스 브랜치의 경우, 최신 커밋의 각 지원 파이프라인 소스에 대한 모든 완료된 파이프라인을 비교합니다.
- 만약 병합 요청 승인 정책이 새로 감지된 상태(
new_needs_triage및new_dismissed)만 찾는 경우, 비교는 소스와 대상 브랜치 사이의 공통 조상에 대해 모든 지원 파이프라인 소스에 대해 수행됩니다. 병합된 결과 파이프라인을 사용하는 경우, 비교는 MR의 대상 브랜치의 끝에 대해 수행됩니다. - 만약 병합 요청 승인 정책이 기존 상태(
detected,confirmed,resolved,dismissed)를 찾는 경우, 비교는 항상 기본 브랜치의 끝에 대해 수행됩니다 (예:main). - 병합 요청 승인 정책이 새로운 및 기존 취약성 상태의 조합을 찾는 경우, 비교는 소스와 대상 브랜치의 공통 조상에 대해 수행됩니다.
- 병합 요청 승인 정책은 병합 요청이 승인을 필요로 하는지 여부를 결정할 때, 결과를 비교할 때 소스 및 대상 브랜치에서의 모든 지원 파이프라인 소스(기반은
CI_PIPELINE_SOURCE변수에 의함)를 고려합니다. 소스가webide인 파이프라인은 지원되지 않습니다. - 16.11 버전부터는 각 선택된 파이프라인의 자식 파이프라인도 비교됩니다. 이는 플래그인
approval_policy_parent_child_pipeline로 사용할 수 있습니다.
미래 병합 요청에서 위험 수용 및 취약성 무시하기
새로 감지된 결과(new_needs_triage 또는 new_dismissed 상태)에 대한 병합 요청 승인 정책의 범위에 대해 고려해야 합니다. 결과가 병합 요청 브랜치에만 존재하고 기본 브랜치에는 존재하지 않는 경우, 결과는 새로 감지된 것으로 간주됩니다. 병합 요청은 이러한 취약성에 대한 “위험 수용”을 승인하고 병합합니다. 이후에 동일한 취약성 중 하나 이상이 감지되면, 해당 상태는 detected 되므로 new_needs_triage 또는 new_dismissed 상태를 대상으로 하는 정책의 범위를 벗어날 수 없습니다. 예를 들면:
- 치명적인 SAST 결과를 차단하는 병합 요청 승인 정책이 생성됩니다. 만약 CVE-1234의 SAST 결과가 승인됐다면, 해당 프로젝트에서 미래의 동일한 위반에 대해 병합 요청 승인이 필요하지 않습니다.
라이선스 승인 정책을 사용하는 경우, 프로젝트, 구성 요소(의존성) 및 라이선스의 조합이 평가 대상입니다. 만약 라이선스가 예외로 승인된 경우, 미래의 병합 요청은 프로젝트, 구성 요소(의존성) 및 라이선스의 동일한 조합에 대해 승인이 필요하지 않습니다. 이 경우 구성 요소의 버전은 고려되지 않습니다. 예를 들면:
-
AGPL-1.0라이선스와 일치하는 새로 감지된 라이선스를 차단하는 라이선스 승인 정책이 생성됩니다.demo프로젝트에서osframework에 변경이 생겨서 정책을 위반했다면, 승인과 병합 후에AGPL-1.0라이선스와 관련된osframework에 대한 미래 병합 요청은 승인이 필요하지 않습니다.
다중 승인
병합 요청 승인 정책이 추가 승인 단계를 필요로 하는 여러 상황이 있습니다. 예를 들면:
-
작업 브랜치에서 보안 작업 수가 줄어들어 대상 브랜치의 보안 작업 수와 더 이상 일치하지 않습니다. 사용자는 CI/CD 구성에서 스캔 작업을 제거함으로써 스캐닝 결과 정책을 건너뛸 수 없습니다.
예시) 기본 브랜치 파이프라인에
sast,secret_detection,container_scanning,dependency_scanning네 개의 보안 스캔이 포함되어 있는 상황을 고려해봅시다. 병합 요청 승인 정책에는container_scanning과dependency_scanning두 개의 스캐너가 필요하다면, 병합 요청에서 정책에 설정된 스캔(예:container_scanning)을 제거한다면 추가 승인이 필요합니다. - 누군가 파이프라인 보안 작업을 중지하면, 사용자는 보안 스캔을 건너뛸 수 없습니다.
- 병합 요청에서 작업이 실패하고
allow_failure: false로 설정된 작업의 경우, 파이프라인이 차단된 상태가 됩니다. - 파이프라인에는 전체 파이프라인이 통과하려면 반드시 성공해야 하는 수동 작업이 있습니다.
승인 요구사항을 평가하기 위해 사용하는 스캔 결과 관리
병합 요청 승인 정책은 파이프라인에서 생성된 스캐너의 아티팩트 보고서를 평가합니다. 병합 요청 승인 정책은 결과를 평가하고 스캔 결과를 기반으로 승인을 결정하여 잠재적인 위험을 식별하고 병합 요청을 차단하고 승인을 요청합니다.
병합 요청 승인 정책은 아티팩트 파일이나 스캐너로 넘어가지 않습니다. 대신에 우리는 아티팩트 보고서에서 결과를 신뢰합니다. 이는 팀이 필요시 스캔 실행 및 공급망을 관리하고 필요에 따라 아티팩트 보고서에서 생성된 스캔 결과(예: 거짓 양성 필터링)를 사용자 정의할 수 있는 유연성을 제공합니다.
예를 들면, 보안 정책 관리 범위를 벗어난 Lock file 조작은 Code owners 또는 external status checks을 통해 완화할 수 있습니다. 추가 정보는 issue 433029을 참조하세요.
속성 “수정 가능” 또는 “잘못된 양성”이 있는 정책 위반을 걸러내세요
불필요한 승인 요구를 피하기 위해 이러한 추가 필터는 가장 실행 가능한 결과에 대해 MR(Merge Request)만 차단하도록 보장합니다.
YAML에서 fix_available를 false로 설정하거나 정책 편집기에서 is not 및 Fix Available로 설정하여, 솔루션이나 교정이 가능한 경우 정책 위반이 아닙니다. 솔루션은 취약성 객체 하단의 Solution 제목 아래에 나타납니다. 교정은 취약성 객체 내에 있는 Resolve with Merge Request 버튼으로 나타납니다.
Resolve with Merge Request 버튼은 다음 기준 중 하나를 충족할 때만 나타납니다:
- GitLab Duo Enterprise에서 Ultimate Tier 프로젝트에서 SAST 취약성이 발견되었을 때
- Ultimate Tier의 프로젝트에서
GIT_STRATEGY: fetch가 설정된 작업에서 컨테이너 스캔 취약성이 발견되었으며, 컨테이너 이미지에 대해 활성화된 저장소에 수정이 있는 경우 - Ultimate Tier의 Node.js 프로젝트에서 yarn으로 관리되는 종속성 스캔 취약성이 발견되었을 때, 프로젝트가 Ultimate Tier에 있고 해당 인스턴스에 FIPS 모드가 비활성화된 경우
Fix Available은 종속성 스캔 및 컨테이너 스캔에만 적용됩니다.
마찬가지로 False Positive 속성을 사용하여 정책에 의해 감지된 결과를 무시할 수 있으며, 정책 편집기에서 false_positive를 false로 설정하거나 속성을 is not 및 False Positive로 설정합니다.
False Positive 속성은 SAST 결과에 대한 취약성 추출 도구에 의해 감지된 결과에만 적용됩니다.
문제 해결
병합 요청 규칙 위젯이 잘못된 또는 중복된 병합 요청 승인 정책을 표시함
GitLab Self-managed 버전 15.0에서 16.4까지, 프로젝트가 그룹에서 내보내져 다른 그룹으로 가져온 경우에 가장 가능성이 높은 원인은 병합 요청 승인 정책 규칙이 있는 프로젝트가 내보낸 프로젝트와는 별도의 프로젝트에 저장되어 있기 때문입니다. 이로 인해 프로젝트에는 가져온 프로젝트 그룹에 존재하지 않는 엔터티를 참조하는 정책 규칙이 포함되어 있습니다. 결과적으로 정책 규칙은 잘못되거나 중복되었거나 둘 다일 수 있습니다.
GitLab 인스턴스에서 모든 잘못된 병합 요청 승인 정책 규칙을 제거하려면, 관리자는 다음 스크립트를 Rails 콘솔에서 실행할 수 있습니다.
Project.joins(:approval_rules).where(approval_rules: { report_type: %i[scan_finding license_scanning] }).where.not(approval_rules: { security_orchestration_policy_configuration_id: nil }).find_in_batches.flat_map do |batch|
batch.map do |project|
# 해당 프로젝트의 설정 ID와 그 구성 ID를 가져옵니다
[project, project.approval_rules.where(report_type: %i[scan_finding license_scanning]).pluck(:security_orchestration_policy_configuration_id).uniq]
end.uniq.map do |project, configuration_ids| # 고유한 프로젝트 및 구성 ID만 가져옵니다
# 프로젝트에 있는 configurations보다 더 많은 configurations가 있으면 추가 configurations이 있는 레코드를 가져옵니다
[project, configuration_ids - project.all_security_orchestration_policy_configurations.pluck(:id)]
end.select { |_project, configuration_ids| configuration_ids.any? }
end.each do |project, configuration_ids|
# 찾은 각 프로젝트 + ghost configuration이 있는 쌍에 대해 해당 프로젝트에서 이러한 규칙을 제거합니다
Security::OrchestrationPolicyConfiguration.where(id: configuration_ids).each do |configuration|
configuration.delete_scan_finding_rules_for_project(project.id)
end
# 새로운 그룹의 정책에서 가능한 규칙을 동기화합니다
Security::ScanResultPolicies::SyncProjectWorker.perform_async(project.id)
end
새로 발견된 CVE들
new_needs_triage 및 new_dismissed를 사용할 때, 일부 결과는 병합 요청에서 발생하지 않는 경우(예: 관련 종속성에 대한 새로운 CVE) 승인이 필요할 수 있습니다. 이러한 결과는 MR 위젯에는 표시되지 않지만 정책 봇 코멘트 및 파이프라인 보고서에 하이라이트로 표시됩니다.
policy.yml이 수동으로 무효화되었음에도 정책은 여전히 적용됨
GitLab 17.2 및 이전 버전에서 policy.yml 파일에 정의된 정책이 더 이상 정책 스키마를 충족하지 않아도 정책이 적용되는 것을 발견할 수 있습니다. 이 문제는 정책 동기화 논리의 버그로 인해 발생합니다.
잠재적인 증상은 다음과 같습니다:
-
approval_settings승인 설정이 브랜치 보호 해제, 강제 푸시 차단 또는 기타 모든 병합 요청에 영향을 미침 -
any_merge_request정책이 여전히 열린 병합 요청에 적용됨
이를 해결하려면 다음을 수행할 수 있습니다:
- 정책을 다시 유효하게 만들기 위해
policy.yml파일을 수동으로 편집합니다. -
policy.yml파일이 저장된 보안 정책 프로젝트를 다시 할당하고 다시 할당합니다.
보안 스캔이 누락된 경우
병합 요청 승인 정책을 사용할 때, 새로운 프로젝트이거나 특정 보안 스캔이 실행되지 않은 경우에는 병합 요청이 차단될 수 있습니다. 이 동작은 시스템에 취약점을 도입하는 위험을 줄이기 위해 설계되었습니다.
예시 시나리오:
-
소스 또는 타겟 브랜치에서 스캔이 누락된 경우
소스 또는 타겟 브랜치 중 어느 한쪽에서 보안 스캔이 누락된 경우, GitLab은 새로운 취약점이 도입되는지를 효과적으로 평가할 수 없습니다. 이러한 경우에는 예방 조치로 승인이 필요합니다.
-
새로운 프로젝트
보안 스캔이 아직 설정되지 않은 새로운 프로젝트의 경우, 모든 병합 요청이 승인이 필요합니다. 이는 프로젝트의 개시부터 보안 검사가 활성화되었음을 보장합니다.
-
스캔 대상 파일이 없는 프로젝트
선정된 보안 스캔과 관련 없는 파일을 포함하는 프로젝트에서도 승인 요구가 여전히 강제됩니다. 이는 모든 프로젝트에서 일관된 보안 관행을 유지합니다.
-
첫 번째 병합 요청
새로운 프로젝트의 첫 번째 병합 요청은 기본 브랜치에 보안 스캔이 없는 경우에도(소스 브랜치에 취약점이 없더라도) 차단될 수 있습니다.
이러한 문제를 해결하기 위해:
- 모든 필요한 보안 스캔이 소스 및 타겟 브랜치에서 성공적으로 구성 및 실행되었는지 확인합니다.
- 새로운 프로젝트의 경우, 병합 요청을 만들기 전에 기본 브랜치에서 필요한 보안 스캔을 설정하고 실행합니다.
- 모든 브랜치에서 보안 스캔이 일관되게 실행되도록 스캔 실행 정책 또는 파이프라인 실행 정책을 고려하세요.
-
fallback_behavior를open과 함께 사용하여 정책 내에서 유효하지 않거나 적용할 수 없는 규칙을 차단하는 것을 방지하세요.
병합 요청 승인 정책 디버깅 지원 요청
GitLab.com 사용자는 “병합 요청 승인 정책 디버깅”이라는 제목의 지원 티켓을 제출할 수 있습니다. 다음 세부 정보를 제공하세요:
- 그룹 경로, 프로젝트 경로 및 선택적으로 병합 요청 ID
- 심각도
- 현재 동작
- 기대 동작
GitLab.com
지원 팀은 로그 (pubsub-sidekiq-inf-gprd*)를 조사하여 실패 “이유”를 식별할 것입니다. 아래는 로그에서의 예시 응답 조각입니다. 병합 승인과 관련된 로그를 찾으려면 이 쿼리를 사용할 수 있습니다: json.event.keyword: "update_approvals" 및 json.project_path: "group-path/project-path". 선택적으로 병합 요청 식별자를 사용하여 더 필터링할 수 있습니다. json.merge_request_iid를 사용하여:
"json": {
"project_path": "group-path/project-path",
"merge_request_iid": 2,
"missing_scans": [
"api_fuzzing"
],
"reason": "Scanner removed by MR",
"event": "update_approvals",
}
GitLab Self-Managed
project-path, api_fuzzing, 및 merge_request와 같은 키워드를 검색합니다. 예시: grep group-path/project-path, 및 grep merge_request. 상관 ID를 아는 경우 상관 ID로 검색할 수 있습니다. 예를 들어, correlation_id의 값이 01HWN2NFABCEDFG이면 01HWN2NFABCEDFG로 검색합니다.
다음 파일에서 검색합니다:
/gitlab/gitlab-rails/production_json.log/gitlab/sidekiq/current
일반적인 실패 이유:
- Scanner removed by MR: 병합 요청 승인 정책은 정책에 정의된 스캐너가 존재하고 비교를 위해 성공적으로 아티팩트를 생성하는 것을 기대합니다.
도움말