Merge Request 승인 정책

Tier: Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated
  • 그룹 수준 검사 결과 정책은 GitLab 15.6에서 소개되었습니다.
  • 검사 결과 정책 기능은 GitLab 16.9에서 Merge Request 승인 정책으로 이름이 변경되었습니다.
note
검사 결과 정책 기능은 GitLab 16.9에서 Merge Request 승인 정책으로 이름이 변경되었습니다.

Merge Request 승인 정책을 사용하여 프로젝트 수준 설정 및 승인 규칙을 검사 결과를 기반으로 강제할 수 있습니다. 예를 들어, 보안 승인 정책은 하나 이상의 보안 스캔 작업 결과를 기반으로 필요에 따라 승인이 필요하도록 하는 보안 승인 정책의 일종입니다. Merge Request 승인 정책은 CI 스캔 작업이 완전히 실행되고 작업 결과 보고서가 완료된 파이프라인에 게시된 작업 아티팩트 보고서를 기반으로 취합되며 취약점 및 라이선스 유형 정책이 해당 작업 아티팩트 보고서를 기반으로 평가됩니다.

note
Merge Request 승인 정책은 보호 대상 브랜치에만 적용됩니다.
note
보호된 브랜치가 생성되거나 삭제되면 정책 승인 규칙이 1분의 지연을 가지고 동기화됩니다.

다음 비디오에서 이전 검사 결과 정책에서 Merge Request 승인 정책으로 변경된 GitLab의 Merge Request 승인 정책에 대한 개요를 제공합니다.

비디오 보기: GitLab 검사 결과 정책 개요.

요구 사항 및 제한 사항

  • 해당 보안 스캔 도구를 추가해야 합니다. 그렇지 않으면 Merge Request 승인 정책이 평가되지 않고 해당 승인은 필요합니다.
  • 보안 정책 프로젝트 당 최대 Merge Request 승인 정책 개수는 다섯 개입니다.
  • 각 정책당 최대 다섯 개의 규칙을 가질 수 있습니다.
  • 모든 구성된 스캐너는 Merge Request의 최신 파이프라인에 있어야 합니다. 그렇지 않으면 일부 취약성 조건을 충족하지 못했더라도 승인이 필요합니다.
  • Merge Request 승인 정책은 작업 아티팩트 보고서에 기재된 결과를 평가하고 승인 요구 사항을 결정하나, 승인 정책은 작업 아티팩트 보고서에서 생성된 검사 결과의 무결성 또는 정토성을 확인하지는 않습니다.

여러 파이프라인을 가진 Merge Request

  • GitLab 16.2에서 플래그와 함께 multi_pipeline_scan_result_policies라는 이름의 플래그로 소개되었습니다. 기본 설정은 비활성화되어 있습니다.
  • GitLab 16.3에서 일반 사용 가능하게 되었습니다. multi_pipeline_scan_result_policies 플래그가 삭제되었습니다.
  • GitLab 16.11에서 부모-자식 파이프라인 지원이 플래그와 함께 approval_policy_parent_child_pipeline라는 이름의 플래그로 소개되었습니다. 기본 설정은 비활성화되어 있습니다.
  • GitLab 17.0에서 GitLab.com에서 활성화됨니다.
Self-Managed형 GitLab에서 기본적으로 부모-자식 파이프라인 지원을 사용할 수 없습니다. 사용하려면 관리자가 approval_policy_parent_child_pipeline이라는 이름의 피처 플래그를 활성화할 수 있습니다.

프로젝트는 여러 파이프라인 유형을 구성할 수 있습니다. 단일 커밋은 여러 파이프라인을 시작할 수 있으며 각각 보안 스캔이 포함될 수 있습니다.

  • GitLab 16.3 이상에서는 Merge Request의 소스 및 대상 브랜치에 대한 최신 커밋의 모든 완료된 파이프라인 결과가 평가되어 Merge Request 승인 정책이 강제됩니다. 온디맨드 DAST 파이프라인은 고려되지 않습니다.
  • GitLab 16.2 및 그 이전 버전에서는 Merge Request 승인 정책이 강제될 때 최신 완료된 파이프라인 결과만 평가되었습니다.

프로젝트가 Merge Request 파이프라인을 사용하는 경우 보안 스캐닝 작업이 파이프라인에 포함되도록 latest 보안 템플릿을 사용해야 합니다. 자세한 내용은 Merge Request 파이프라인과 보안 스캔 도구 사용를 참조하십시오.

Merge Request 승인 정책 편집기

note
프로젝트 소유자만 보안 정책 프로젝트를 선택할 권한이 있습니다.

정책을 완료하면 편집기 하단에서 Merge Request으로 구성을 선택하여 저장합니다. 이렇게 하면 구성한 보안 정책 프로젝트의 Merge Request으로 리디렉션이 이루어집니다. 보안 정책 프로젝트가 프로젝트에 링크되지 않은 경우, GitLab은 해당 프로젝트를 생성합니다. 기존 정책은 편집기 인터페이스에서 정책 삭제를 선택하여 제거할 수도 있습니다.

대부분의 정책 변경은 Merge Request이 Merge되는 즉시 적용됩니다. Merge Request을 통과하지 않고 기본 브랜치에 직접 커밋하는 경우 정책 변경이 적용되기까지 최대 10분이 소요될 수 있습니다.

정책 편집기는 YAML 모드 및 규칙 모드를 지원합니다.

note
다수의 프로젝트로부터 생성된 Merge Request 승인 정책을 전파하는 데 시간이 소요될 수 있습니다.

Merge Request 승인 정책 스키마

Merge Request 승인 정책을 가진 YAML 파일은 approval_policy 키 아래 중첩된 Merge Request 승인 정책 스키마 객체의 배열로 구성됩니다. approval_policy 키 아래 최대 다섯 개의 정책을 구성할 수 있습니다.

note
Merge Request 승인 정책은 scan_result_policy 키 아래 정의되었습니다. GitLab 17.0 이전까지 정책은 두 키 모두에서 정의될 수 있습니다. GitLab 17.0부터는 approval_policy 키만 지원됩니다.

새로운 정책을 저장할 때, GitLab은 이 JSON 스키마에 대해 내용을 유효성 검사합니다. JSON 스키마를 읽는 방법에 익숙하지 않다면, 다음 섹션과 테이블에서 대체로 제공됩니다.

필드 타입 필수 여부 가능한 값 설명
approval_policy array of Merge Request Approval Policy true   Merge Request 승인 정책의 디렉터리 (최대 5개).

Merge Request 승인 정책 스키마

  • approval_settings 필드는 flag인 scan_result_policies_block_unprotecting_branches, scan_result_any_merge_request, 또는 scan_result_policies_block_force_push와 함께 GitLab 16.4에서 소개되었습니다. approval_settings 섹션에 대한 자세한 내용은 아래를 참조하십시오.
필드 타입 필수 여부 가능한 값 설명
name string true   정책의 이름. 최대 255자.
description string false   정책의 설명.
enabled boolean true true, false 정책을 활성화(true) 또는 비활성화(false)하는 플래그.
rules 규칙의 배열 true   정책이 적용되는 규칙 디렉터리.
actions 작업의 배열 false   정책이 시행하는 작업 디렉터리.
approval_settings 객체 false   정책이 무시한 프로젝트 설정.
fallback_behavior 객체 false   무효이거나 시행할 수 없는 규칙에 영향을 주는 설정.

scan_finding rule type

  • 합병 요청 승인 정책 필드 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이라는 플래그와 함께 일반적으로 사용 가능해졌습니다. 특징 플래그가 제거되었습니다.

이 규칙은 보안 검사 결과를 기반으로 정의된 작업을 시행합니다.

필드 유형 필수 가능한 값 설명
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 [] 또는 newly_detected, detected, confirmed, resolved, dismissed, new_needs_triage, new_dismissed 모든 취약점은 두 가지 범주로 나뉩니다:

신규 감지 취약점 - newly_detected 정책 옵션은 Merge Request 브랜치 자체에서 식별된 취약점을 나타냅니다. 이 정책 옵션은 취약점이 기존의 기본 브랜치에는 없지만 현재 브랜치에 식별된 경우에 적용됩니다. 이 정책 옵션은 취약점이 신규로 감지되었는지 여부를 알기 위해 파이프라인이 완료될 때까지 평가되므로 Merge Request이 파이프라인 및 필요한 보안 검사가 완료될 때까지 차단됩니다. newly_detected 옵션은 다음 두 가지 상태를 고려합니다:

• 감지됨
• 기각됨

new_needs_triage 옵션은 상태를 고려합니다

• 감지됨

new_dismissed 옵션은 상태를 고려합니다

• 기각됨

기존 취약점 - 이러한 정책 옵션은 즉시 평가되며 파이프라인 완료와는 무관하며 기본 브랜치에서 이전에 감지된 취약점만을 고려합니다.

• Detected - 정책은 감지된 상태의 취약점을 찾습니다.
• Confirmed - 정책은 확인된 상태의 취약점을 찾습니다.
• Dismisse - 정책은 기각된 상태의 취약점을 찾습니다.
• Resolved - 정책은 해결된 상태의 취약점을 찾습니다.

빈 배열 []은 newly_detected과 동일한 상태를 covered합니다. 이는 ['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 기준은 연령 비교에 사용되는 older than(greater_than) 또는 younger than(less_than)을 지정합니다.
- value 기준은 취약점 연령을 나타내는 숫자 값을 지정합니다.
- interval 기준은 취약점 연령의 단위를 나타냅니다: day, week, month, 또는 year.

예: operator: greater_than, value: 30, interval: day.

license_finding rule type

  • GitLab 15.9에 도입되었으며 license_scanning_policies라는 플래그와 함께 소개되었습니다.
  • GitLab 15.11에서 일반적으로 사용 가능해졌습니다. 특징 플래그 license_scanning_policies가 제거되었습니다.
  • branch_exceptions 필드는 GitLab 16.3에 도입되었으며 security_policies_branch_exceptions이라는 플래그와 함께 기본 활성화되었습니다. GitLab 16.5에서 일반적으로 사용 가능해졌습니다. 특징 플래그가 제거되었습니다.

이 규칙은 라이선스 검색 결과를 기반으로 정의된 작업을 시행합니다.

필드 유형 필수 가능한 값 설명
type string true license_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 브랜치 이름 이 규칙에서 제외할 브랜치입니다.
match_on_inclusion_license boolean true true, false 규칙이 license_types로 나열된 라이선스의 포함 또는 제외와 일치하는지 여부입니다.
license_types array of string true 라이선스 유형 SPDX license names와 일치시킬 라이선스 유형입니다. 예: 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에서 도입되었습니다. security_policies_branch_exceptions라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다. GitLab 16.5에서 일반적으로 사용 가능 합니다. 피처 플래그가 제거되었습니다.
  • any_merge_request rule type은 GitLab 16.4에서 도입되었습니다. 기본적으로 활성화되어 있습니다. GitLab 16.6에서 일반적으로 사용 가능 합니다. 피처 플래그가 제거되었습니다.

이 규칙은 커밋 서명을 기반으로 어떠한 Merge Request에 대한 정의된 작업을 강제합니다.

Field Type Required Possible values Description
type string true any_merge_request 규칙의 유형입니다.
branches array of string branch_type 필드가 없는 경우 true [] 또는 브랜치 이름 적용 대상은 보호된 대상 브랜치에만 해당됩니다. 빈 배열 []은 모든 보호된 대상 브랜치에 규칙을 적용합니다. branch_type 필드와 함께 사용할 수 없습니다.
branch_type string branches 필드가 없는 경우 true default 또는 protected 주어진 정책이 적용되는 보호된 브랜치의 유형입니다. branches 필드와 함께 사용할 수 없습니다. 기본 브랜치도 protected 여야 합니다.
branch_exceptions array of string false 브랜치 이름 이 규칙에서 제외할 브랜치입니다.
commits string true any, unsigned 규칙이 어떤 커밋에 대해 일치하는지, 또는 Merge Request에서만 무인 커밋이 검색되는지 여부입니다.

require_approval action type

이 작업은 정의된 정책 중 적어도 하나의 규칙이 충족되었을 때 필요한 승인 규칙을 설정합니다.

Field Type Required Possible values Description
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 action type

이 기능의 사용 가능성은 피처 플래그로 제어됩니다. 자세한 정보는 이력을 참조하세요.

이 작업은 정책 위반을 감지할 때 Merge Request에서 봇 메시지의 구성을 활성화합니다. 이 작업이 지정되지 않은 경우, 기본적으로 봇 메시지가 활성화됩니다. 여러 정책이 정의된 경우 봇 메시지는 적어도 하나의 정책이 send_bot_message 작업이 활성화되어 있어야만 전송됩니다.

Field Type Required Possible values Description
type string true send_bot_message 작업의 유형입니다.
enabled boolean true true, false 정책 위반이 감지될 때 봇 메시지를 생성해야 하는지 여부입니다. 기본값: true

봇 메시지 예시

scan_results_example_bot_message_v17_0

scan_results_example_bot_message_v17_0

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에서 활성화되었습니다.
  • 위의 필드는 GitLab 16.7에서 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에서 활성화되었습니다.
  • 위의 필드는 GitLab 16.7에서 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에서 활성화되었습니다.
  • 위의 필드는 GitLab 16.7에서 Self-Managed에서 활성화되었습니다.
  • 피처 플래그 scan_result_policies_block_force_push가 GitLab 16.8에서 제거되었습니다.
기본적으로 block_branch_modification 필드는 Self-Managed형 GitLab에서 사용 가능합니다. 기능을 숨기려면 관리자가 scan_result_policies_block_unprotecting_branches라는 피처 플래그를 비활성화할 수 있습니다. GitLab.com 및 GitLab Dedicated에서 이 기능은 사용 가능합니다.

정책에 설정된 설정은 프로젝트의 설정을 덮어씁니다.

Field Type Required Possible values Applicable rule type Description
block_branch_modification boolean false true, false 전체 활성화되면 사용자가 보호된 브랜치 디렉터리에서 브랜치를 제거하거나 보호된 브랜치를 삭제하거나 기본 브랜치를 변경하는 것을 방지합니다. 이는 사용자가 취약한 코드를 Merge하기 위해 브랜치의 보호 상태를 제거하는 것을 방지합니다. 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 Any merge request 활성화되면 Merge Request 작성자는 자신의 MR에 승인을 할 수 없습니다. 이는 코드 작성자가 취약점을 도입하고 코드를 Merge하기 위해 코드 승인을 할 수 없도록 합니다.
prevent_approval_by_commit_author boolean false true, false Any merge request 활성화되면 MR에 코드를 기여한 사용자는 승인 대상에서 제외됩니다. 이는 코드 커밋러가 취약점을 도입하고 코드를 Merge하기 위해 코드를 승인할 수 없도록 합니다.
remove_approvals_with_new_commit boolean false true, false Any merge request 활성화되면 MR이 Merge하기 위해 필요한 모든 승인을 받은 후 새로운 커밋이 추가되면 새로운 승인이 필요합니다. 이는 새로운 커밋이 취약점을 포함할 수 없도록 합니다.
require_password_to_approve boolean false true, false Any merge request 활성화되면 승인에 비밀번호 확인이 필요합니다. 비밀번호 확인은 추가적인 보안 계층을 추가합니다.
prevent_pushing_and_force_pushing boolean false true, false 전체 활성화되면 보호된 브랜치로 푸시 및 강제 푸시를 방지합니다. 이는 사용자가 Merge Request 프로세스를 우회하여 취약한 코드를 브랜치에 추가하는 것을 방지합니다.

fallback_behavior

플래그: Self-Managed형 GitLab에서는 기본적으로 fallback_behavior 필드를 사용할 수 있습니다. 기능을 숨기려면 관리자가 security_scan_result_policies_unblock_fail_open_approval_rules라는 피처 플래그를 비활성화할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 있습니다.

필드 유형 필수 가능한 값 설명
fail string false open 또는 closed closed (기본): 정책의 부적합하거나 적용할 수 없는 규칙은 승인이 필요합니다. open: 정책의 부적합한 또는 적용할 수 없는 규칙은 승인이 필요하지 않습니다.

보안 Merge Request 승인 정책 프로젝트 예시

.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:
    - newly_detected
    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 역할을 가진 프로젝트 멤버로부터 승인이 필요합니다.

Merge Request 승인 정책 편집기 예시

이 예시를 Merge Request 승인 정책 편집기의 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:
  - newly_detected
actions:
- type: require_approval
  approvals_required: 1
  user_approvers:
  - adalberto.dare

Merge Request 승인 정책 승인 범위 이해

  • scan_finding의 브랜치 비교 로직이 GitLab 16.8에서 변경되었습니다과 관련한 플래그 scan_result_policy_merge_base_pipeline으로 비활성화되었습니다.
  • GitLab 16.9에서 일반적으로 사용 가능합니다. feature flag scan_result_policy_merge_base_pipeline은 삭제되었습니다.

Merge Request 승인 정책 비교 범위

  • Merge Request에서 승인이 필요한 시점을 결정하기 위해 각 지원되는 파이프라인 소스의 완료된 파이프라인을 소스와 대상 브랜치 (예: feature/main)에 대해 비교합니다. 이는 스캔 결과의 가장 포괄적인 평가를 보장합니다.
  • 소스 브랜치의 비교 파이프라인은 소스 브랜치의 최신 커밋에 대해 각 지원되는 파이프라인 소스의 모든 완료된 파이프라인입니다.
  • 대상 브랜치의 경우 모든 공통 조상의 완료된 파이프라인을 비교합니다.
  • Merge Request 승인 정책은 승인이 필요한지 여부를 결정할 때 소스와 대상 브랜치의 모든 지원되는 파이프라인 소스를 고려합니다(CI_PIPELINE_SOURCE 변수를 기반으로 함). 소스 webide는 지원되지 않습니다.
  • GitLab 16.11 이후에는 선택된 파이프라인의 자식 파이프라인도 비교 대상으로 고려됩니다. 이는 approval_policy_parent_child_pipeline이라는 플래그로 사용할 수 있습니다.

리스크 수용 및 향후 Merge Request에서의 취약점 무시

newly_detected 발견으로 범위가 지정된 Merge Request 승인 정책의 경우, 이 취약점 상태의 영향을 이해하는 것이 중요합니다. 취약점이 newly_detected 상태인 경우 Merge Request의 브랜치에는 해당 취약점이 있지만 기본 브랜치에는 없는 것입니다. Merge Request의 브랜치에 newly_detected 취약점이 있을 때, 해당 취약점에 대한 승인 및 Merge을 통해 승인자들은 해당 취약점의 ‘위험 수용’을 하는 것입니다. 해당 시점 이후에 동일한 취약점 중 하나 이상이 감지되더라도 이들의 상태는 previously_detected가 되어 newly_detected 취약점을 대상으로한 정책의 적용 대상에서 제외됩니다. 예:

  • CVE-1234에 대한 SAST 결과(findings)을 차단하는 Merge Request 승인 정책이 생성되었습니다. 만약 CVE-1234에 대한 SAST 결과(findings)이 승인되면, 동일한 위반을 포함하는 향후 Merge Request에 대해서는 프로젝트에서 승인이 필요하지 않습니다.

라이선스 승인 정책을 사용할 때 프로젝트, 컴포넌트(의존성) 및 라이선스의 결합이 평가됩니다. 특정 라이선스가 예외로 승인된 경우, 새로운 버전의 동일한 패키지의 업데이트는 승인자가 다시 승인할 필요가 없습니다. 예:

  • AGPL-1.0과 일치하는 신규 감지된 라이선스를 차단하는 라이선스 승인 정책이 생성되었습니다. 프로젝트 demo에서 osframework에 대한 변경사항이 해당 정책을 위반합니다. 허용되고 Merge된다면, 프로젝트 demo에서 osframework에 대한 AGPL-1.0 라이선스를 가지고 하는 향후 Merge Request에 대해 승인이 필요하지 않습니다.

다중 승인

Merge Request 승인 정책이 추가 승인 단계를 요구하는 여러 상황이 있습니다. 예를 들어:

  • 작업 브랜치에서 보안 작업의 수가 줄어들어 더 이상 대상 브랜치의 보안 작업 수와 일치하지 않습니다. 사용자는 CI/CD 구성에서 스캔 작업을 제거함으로써 Scanning Result Policies를 건너뛸 수 없습니다. Merge Request 승인 정책에서 구성된 스캔만이 제거 여부에 대해 확인됩니다.

예시에서 기본 브랜치 파이프라인에는 sast, secret_detection, container_scanning, dependency_scanning의 4개 보안 스캔이 있습니다. Merge Request 승인 정책은 container_scanning 및 dependency_scanning 두 개의 스캐너를 강제화합니다. Merge Request에서 Merge Request 승인 정책에 구성된 스캔을 삭제할 경우 container_scanning이 추가적인 승인이 필요합니다. - 누군가가 파이프라인 보안 작업을 중단하고 스캔을 건너뛸 수 없는 상태입니다. - Merge Request에서 작업이 실패하고 allow_failure: false로 설정된 경우, 파이프라인이 차단 상태입니다. - 파이프라인에는 전체 파이프라인을 통과하기 위해 성공적으로 실행되어야 하는 매뉴얼 작업이 있습니다.

스캔 결과 평가를 관리하는 방법

Merge Request 승인 정책은 파이프라인이 완료된 후에 생성된 스캐너의 아티팩트 보고서를 평가합니다. Merge Request 승인 정책은 결과를 평가하고 스캔 결과에 기반하여 승인을 결정하여 잠재적인 위험을 식별하고, Merge Request을 차단하고, 승인을 요구하는 데 중점을 둡니다.

Merge Request 승인 정책은 아티팩트 파일이나 스캐너까지 넘어가지 않습니다. 대신, 우리는 아티팩트 보고서의 결과를 신뢰합니다. 이로써 팀은 필요시 스캔 실행 및 공급망을 관리하고, 아티팩트 보고서에서 생성된 스캔 결과를 사용자 정의할 수 있습니다(예: 거짓 긍정을 걸러내는 등).

예를 들어, 잠금 파일 조작은 보안 정책 관리의 범위를 벗어나지만 코드 소유자나 외부 상태 확인을 사용하여 완화될 수 있습니다. 자세한 정보는 issue 433029을 참조하십시오.

스캔 결과 평가

알려진 문제점

우리는 epic 11020에서 스캔 결과 평가의 일부 혼동되는 공통 영역을 확인하고 해결해야할 필요성을 확인했습니다. 아래는 알려진 문제점의 몇 가지 예시입니다:

  • newly_detected를 사용할 때, 일부 결과는 Merge Request에 의해 도입되지 않은 경우에도 승인이 필요할 수 있습니다(예: 관련 의존성의 새로운 CVE).
  • Merge Request 승인 정책에서 승인이 필요한 결과나 오류가 보안 MR 위젯에 명확하지 않을 수 있습니다. issue 428518에서 merge base가 도입되었고, 일부 경우에는 해결되었습니다. 더 많은 세부 정보를 표시하여 보안 정책 위반의 원인을 명확하게 하는 데 대한 지원은 epic 11185에서 제안됩니다.
  • 보안 정책 위반은 MR 위젯에 표시되는 결과와는 다릅니다. 일부 위반은 MR 위젯에 표시되지 않을 수 있습니다. 우리는 epic 11020에서 기능을 조화시키고, epic 11185에서 Merge Request에서 정책 위반을 명시적으로 표시하기 위해 작업 중입니다.
  • 프로젝트에 결합된 Merge Result 파이프라인과 MR 생성을 위한 브랜치 파이프라인이 활성화되어 있는 경우, 소스와 대상 브랜치 간의 비교는 소스 브랜치의 파이프라인이 완료된 순서에 따라 달라집니다. 이는 레이스 조건을 발생시킬 수 있으며, issue 384927에서 제안된 해결책을 선택할 수 있습니다. 승인은 선택한 대상 브랜치 파이프라인에 따라 다르게 작동할 수 있습니다.

실험적인 기능

Status: Experiment

보안 정책 범위

전제 조건:

  • 이 실험적인 기능을 활성화하려면 그룹 소유자 또는 관리자가 실험적인 기능을 활성화해야 합니다:
    1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
    2. 설정 > 일반을 선택합니다.
    3. 권한 및 그룹 기능을 확장합니다.
    4. Security Policy Scopes 확인란을 선택합니다.

    5. 선택 사항입니다. 모든 하위 그룹에 대해 강제 적용을 선택합니다.

      설정이 모든 하위 그룹에 대해 강제 적용되지 않는 경우, 하위 그룹 소유자는 하위 그룹당 설정을 관리할 수 있습니다.

저희 실험적인 기능에 대한 피드백이 있으신가요? 의견을 알려주세요! 아래의 피드백 이슈에서 의견을 공유해 주세요.

보안 정책 시행은 먼저 그룹, 하위 그룹 또는 프로젝트와 보안 정책을 포함하는 보안 정책 프로젝트 간의 연결을 수립하는 것에 달려 있습니다. 예를 들어, 그룹에 정책을 연결하는 경우, 그룹 소유자가 보안 정책 프로젝트로의 링크를 작성해야 합니다. 그런 다음, 보안 정책 프로젝트의 모든 정책은 그룹의 모든 프로젝트에 의해 상속됩니다.

보안 정책의 범위를 다음과 같이 세분화할 수 있습니다:

  • 라벨이 있는 준수 프레임워크가 포함된 프로젝트만 _포함_합니다.
  • 선택한 프로젝트를 _포함하거나 제외_할 수 있습니다.

정책 범위 스키마

필드 타입 필수 여부 가능한 값 설명
policy_scope object false compliance_frameworks, projects 준수 프레임워크 레이블 또는 정의한 프로젝트를 기반으로 정책의 범위를 지정합니다.

policy_scope 범위 유형

필드 타입 가능한 값 설명
compliance_frameworks array   배열 내 객체의 id 키에 따라 적용 범위 내의 준수 프레임워크의 ID 디렉터리입니다.
projects object including, excluding excluding: 또는 including:를 사용한 다음, 포함하거나 제외할 프로젝트의 ID 디렉터리을, id 키에 따라 배열 내 객체로 나타냅니다.

보안 정책 스코프가 포함된 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: 1
    severity_levels:
    - critical
    vulnerability_states:
    - newly_detected
  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

문제 해결

Merge Request 규칙 위젯이 Merge Request 승인 정책이 유효하지 않거나 중복되었다고 표시됨

Tier: Ultimate Offering: Self-Managed, GitLab Dedicated

GitLab Self-Managed 15.0부터 16.4까지, 프로젝트가 그룹에서 내보내져 다른 그룹으로 가져온 경우에 가장 가능한 원인은 해당 프로젝트에 Merge Request 승인 정책 규칙이 포함된 별도 프로젝트에 저장되었기 때문입니다. 결과적으로 프로젝트에는 가져온 그룹의 존재하지 않는 엔터티를 참조하는 정책 규칙이 포함되어 있습니다. 이로 인해 정책 규칙이 유효하지 않거나 중복되거나 둘 다일 수 있습니다.

GitLab 인스턴스에서 모든 유효하지 않은 Merge Request 승인 정책 규칙을 제거하려면 관리자가 레일 콘솔에서 다음 스크립트를 실행할 수 있습니다. 

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 가져오기
    [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 조합 만 챙깁니다
    # 프로젝트에 사용 가능한 구성보다 더 많은 구성을 발견하면 추가 구성이 있는 레코드를 챙깁니다
    [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|
  # 찾은 프로젝트 + 유령 구성 쌍마다 해당 프로젝트의 이러한 규칙을 제거합니다
  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

보안 승인 정책 디버깅

GitLab SaaS 사용자는 “Merge Request 승인 정책 디버깅”이라는 제목의 지원 티켓을 제출할 수 있습니다. 다음과 같은 세부 정보를 제공하십시오:

  • 그룹 경로, 프로젝트 경로 및 선택 사항으로 Merge Request ID
  • 심각도
  • 현재 동작
  • 기대 동작

GitLab SaaS

지원 팀은 로그 (pubsub-sidekiq-inf-gprd*)를 조사하여 실패 “이유”를 식별합니다. 아래는 로그에서 예시 응답 스니펫입니다. 이 쿼리를 사용하여 승인과 관련된 로그를 찾을 수 있습니다: json.event.keyword: "update_approvals" 및 json.project_path: "group-path/project-path". 선택적으로 Merge Request 식별자를 사용하여 더 필터링할 수 있습니다. 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

프로젝트-경로, api_fuzzing, 및 Merge Request과 같은 키워드를 검색합니다. 예: grep group-path/project-path, 및 grep merge_request. Correlation ID를 알고있는 경우 correlation ID로 검색할 수 있습니다. 예를 들어, correlation_id의 값이 01HWN2NFABCEDFG이면 01HWN2NFABCEDFG를 검색합니다. 다음 파일에서 검색합니다:

  • /gitlab/gitlab-rails/production_json.log
  • /gitlab/sidekiq/current

일반적인 실패 이유:

  • Scanner removed by MR: Merge Request 승인 정책은 정책에 정의된 스캐너가 존재하고 비교를 위해 성공적으로 아티팩트를 생성하는 것을 기대합니다.