병합 요청 승인 정책 (이전: 스캔 결과 정책)

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
  • 그룹 수준 스캔 결과 정책은 GitLab 15.6에 소개되었습니다.
  • 스캔 결과 정책 기능은 GitLab 16.9에서 병합 요청 승인 정책으로 이름이 변경되었습니다.
note
스캔 결과 정책 기능은 GitLab 16.9에서 병합 요청 승인 정책으로 이름이 변경되었습니다.

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

note
병합 요청 승인 정책은 보호된 대상 브랜치에만 적용됩니다. 보호된 대상 브랜치에만 적용됩니다.
note
보호된 브랜치가 생성 또는 삭제될 때, 1분의 지연을 가진 채로 정책 승인 규칙이 동기화됩니다.

다음 비디오에서 GitLab 병합 요청 승인 정책에 대한 개요를 확인할 수 있습니다 (이전 스캔 결과 정책):

비디오 보기: GitLab 스캔 결과 정책 개요.

요구 사항 및 제한 사항

  • 해당 보안 스캔 도구들을 추가해야합니다. 그렇지 않으면 병합 요청 승인 정책은 평가되지 않으며 해당 승인이 필요한 상태로 유지됩니다.
  • 보안 정책 프로젝트 당 최대 병합 요청 승인 정책 수는 5개입니다.
  • 각 정책당 최대 5개의 규칙을 가질 수 있습니다.
  • 구성된 모든 스캐너들이 병합 요청의 최신 파이프라인에 있어야합니다. 그렇지 않으면 일부 취약점 기준을 충족하지 못하더라도 승인이 필요합니다.
  • 병합 요청 승인 정책은 작업 보고서를 기반으로 결과를 평가하고 승인 요구 사항을 결정하지만, 승인 정책은 작업 보고서에서 생성된 스캔 결과의 무결성 또는 진실성을 확인하지는 않습니다.

병합 요청과 여러 파이프라인

  • GitLab 16.2에서 도입되었습니다. 기본값으로 비활성화된 multi_pipeline_scan_result_policies라는 플래그와 함께.
  • GitLab 16.3에서 일반적으로 사용 가능해졌습니다. 기능 플래그 multi_pipeline_scan_result_policies가 제거되었습니다.

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

  • GitLab 16.3 이상에서는 병합 요청의 소스 및 대상 브랜치의 최신 커밋에 대한 모든 완료된 파이프라인의 결과가 평가되어 병합 요청 승인 정책이 시행됩니다. 부모-자식 파이프라인 및 온디맨드 DAST 파이프라인은 고려되지 않습니다.
  • GitLab 16.2 이전에는 병합 요청 승인 정책을 강제로 시행할 때 가장 최근의 완료된 파이프라인 결과만 평가되었습니다.

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

병합 요청 승인 정책 편집기

  • GitLab 14.8에서 도입되었습니다.
  • GitLab 15.6에서 기본적으로 활성화되었습니다.
note
프로젝트 소유자만 권한이 있습니다. 보안 정책 프로젝트를 선택할 수 있습니다.

정책 작성이 완료되면 편집기 하단의 병합 요청 편집으로 구성을 선택하여 저장합니다. 이렇게 하면 프로젝트 구성 보안 정책 프로젝트의 병합 요청으로 리디렉션됩니다. 보안 정책 프로젝트가 프로젝트에 연결되어 있지 않은 경우, GitLab은 이를 위해 프로젝트를 생성합니다. 기존 정책은 편집기 인터페이스 하단의 정책 삭제를 선택하여 제거할 수 있습니다.

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

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

note
대규모 프로젝트 그룹에 대한 생성된 병합 요청 승인 정책의 전파에는 시간이 걸릴 수 있습니다.

병합 요청 승인 정책 스키마

병합 요청 승인 정책이 포함된 YAML 파일은 approval_policy 키 하위에 중첩된 병합 요청 승인 정책 스키마와 일치하는 객체 배열로 구성됩니다. approval_policy 키 하위에 최대 다섯 가지 정책을 구성할 수 있습니다.

참고: 병합 요청 승인 정책은 scan_result_policy 키 하위에 정의되었습니다. GitLab 17.0 이전에는 정책을 두 키 모두에 정의할 수 있었습니다. GitLab 17.0부터는 approval_policy 키만 지원됩니다.

새로운 정책을 저장할 때, GitLab은 해당 내용을 이 JSON 스키마에 대해 유효성을 검사합니다. JSON 스키마의 읽는 방법을 잘 모르는 경우, 다음 섹션과 표가 대안을 제공합니다.

필드 타입 필수 가능한 값 설명
approval_policy 병합 요청 승인 정책의 array 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 true   정책이 적용되는 규칙 목록.
actions 동작의 array false   정책이 시행하는 동작 목록.
approval_settings 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에서 포괄적으로 사용 가능하며, 플래그가 제거되었습니다.

이 규칙은 보안 스캔 결과를 기반으로 정의된 동작을 강제합니다.

필드 타입 필수 가능한 값 설명
type string true scan_finding 규칙 유형.
branches string의 array branches 필드가 존재하지 않으면 필수 [] 또는 브랜치 이름 적용 대상은 보호된 대상 브랜치에만 해당됩니다. 빈 배열인 []은 모든 보호된 대상 브랜치에 규칙을 적용합니다. branch_type 필드와 함께 사용할 수 없습니다.
branch_type string branches 필드가 존재하지 않으면 필수 default 또는 protected 주어진 정책이 적용되는 보호된 브랜치의 유형. branches 필드와 함께 사용할 수 없습니다. 기본 브랜치는 반드시 protected여야 합니다.
branch_exceptions string의 array false 브랜치 이름 이 규칙에서 제외되는 브랜치 이름.
scanners string의 array true sast, secret_detection, dependency_scanning, container_scanning, dast, coverage_fuzzing, api_fuzzing 이 규칙에 대한 보안 스캐너. sast는 SAST 및 SAST IaC 스캐너의 결과를 포함합니다.
vulnerabilities_allowed integer true 0 이상의 값 이 규칙을 고려하기 위해 허용되는 취약점의 수.
severity_levels string의 array true info, unknown, low, medium, high, critical 이 규칙에서 고려하는 심각도 수준.
vulnerability_states string의 array true [] 또는 newly_detected, detected, confirmed, resolved, dismissed, new_needs_triage, new_dismissed 모든 취약점은 두 가지 범주로 나뉩니다:

신규 감지된 취약점 - newly_detected 정책 옵션은 현재 기본 브랜치에는 존재하지 않지만 병합 요청 브랜치에서 식별된 취약점을 다룹니다. 이 정책 옵션은 규칙을 평가하기 위해 파이프라인이 완료될 때까지 기다려야 합니다. 파이프라인 및 필수 보안 스캔이 완료되어야만 정책이 평가됩니다. 병합 요청은 파이프라인 및 필요한 보안 스캔이 완료될 때까지 차단됩니다. newly_detected 옵션은 다음 두 상태를 고려합니다:

• 감지됨
• 삭제됨

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

• 감지됨

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

• 삭제됨

기존 취약점 - 이러한 정책 옵션들은 즉시 평가되며, 기본 브랜치에서 이전에 감지된 취약점만을 고려합니다.

• 감지됨 - 정책은 감지된 상태의 취약점을 찾습니다.
• 확인됨 - 정책은 확인된 상태의 취약점을 찾습니다.
• 삭제됨 - 정책은 삭제된 상태의 취약점을 찾습니다.
• 해결됨 - 정책은 해결된 상태의 취약점을 찾습니다.

빈 배열인 []은 newly_detected와 동일한 상태를 포함합니다. ['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) 또는 더 작음(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 boolean true true, false cautionGitLab 16.9에서 폐지됨. 규칙이 license_types에 나열된 라이선스의 포함 또는 제외를 일치시키는지 여부입니다. 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에서 도입됨. security_policies_branch_exceptions라는 플래그로 함께 도입됨. 기본적으로 활성화됨. 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 주어진 정책이 적용되는 보호된 브랜치의 유형입니다. branches 필드와 함께 사용할 수 없습니다. 기본 브랜치는 반드시 protected 여야 합니다.
branch_exceptions array of string false 브랜치 이름 이 규칙에서 제외할 브랜치입니다.
commits string true any, unsigned 이 규칙이 모든 커밋에 대해 일치하는지 또는 병합 요청에서 미사인 커밋이 감지될 때에만 일치하는지 여부입니다.

require_approval 액션 유형

이 작업은 지정된 정책에서 적어도 하나의 규칙에 대해 조건이 충족되었을 때 승인 규칙을 필요로 하는 것으로 설정합니다.

필드 유형 필수 가능한 값 설명
type string true require_approval 작업의 유형입니다.
approvals_required integer true 0 이상의 정수 필요한 MR(Merge Request) 승인 수입니다.
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) 승인자로 고려할 역할입니다. 승인할 수 있는 사용자입니다.

approval_settings

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

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

필드 유형 필수 가능한 값 적용 가능한 규칙 유형 설명
block_branch_modification boolean false true, false All 활성화되면 보호된 브랜치 목록에서 브랜치를 제거하거나 보호된 브랜치를 삭제하거나, 해당 브랜치가 보안 정책에 포함된 경우 기본 브랜치를 변경하는 것을 막습니다. 이렇게 하면 사용자가 취약한 코드를 병합하기 위해 브랜치의 보호 상태를 제거할 수 없도록 보장합니다. branches, branch_type, policy_scope에서 감지된 취약점 여부와 관계없이 강제됩니다.
block_group_branch_modification boolean or object false true, false, { enabled: boolean, exceptions: [string] } All 활성화되면 정책이 적용되는 모든 그룹에서 그룹 수준의 보호된 브랜치를 제거하는 것을 방지합니다. block_branch_modification이 true인 경우 암시적으로 true로 기본 설정됩니다. branches, branch_type 및 policy_scope를 기반으로 감지된 취약점 여부와 관계없이 강제됩니다.
prevent_approval_by_author boolean false true, false Any merge request 활성화되면 MR(Merge Request) 작성자는 자신의 MR을 승인할 수 없습니다. 이렇게 하면 코드 작성자가 취약성을 도입하고 코드를 승인해서 병합할 수 없도록 보장합니다.
prevent_approval_by_commit_author boolean false true, false Any merge request 활성화되면 MR에 코드를 기여한 사용자는 승인할 수 없습니다. 이렇게 하면 코드 커밋자가 취약성을 도입하고 코드를 승인해서 병합할 수 없도록 보장합니다.
remove_approvals_with_new_commit boolean false true, false Any merge request 활성화되면 MR이 병합을 위해 필요한 모든 승인을 받은 후 새로운 커밋이 추가되면 새로운 승인이 필요합니다. 이렇게 하면 새로운 커밋이 도입될 수 있는 새로운 취약성을 보장하기 위해 새로운 승인이 필요합니다.
require_password_to_approve boolean false true, false Any merge request 활성화되면 승인에 암호 확인이 있습니다. 암호 확인은 추가 보안 층을 추가합니다.
prevent_pushing_and_force_pushing boolean false true, false All 활성화되면 보호된 브랜치에 대해 사용자가 밀어넣거나 강제로 밀어넣는 것을 방지합니다. 이렇게 하면 사용자가 병합 요청 프로세스를 우회하여 취약한 코드를 브랜치에 추가할 수 없도록 보장합니다.

보안 병합 요청 승인 정책 프로젝트 예시

.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 역할을 가진 프로젝트 구성원으로부터 승인이 필요합니다.

병합 요청 승인 정책 편집기 예시

이 예시는 병합 요청 승인 정책 편집기의 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

병합 요청 승인 정책 승인 범위 이해

  • scan_finding의 브랜치 비교 논리가 GitLab 16.8에서 변경되었습니다. 이름이 scan_result_policy_merge_base_pipeline인 기능 플래그로 기본적으로 비활성화되어 있습니다.
  • GitLab 16.9에서 일반 사용 가능합니다. scan_result_policy_merge_base_pipeline 기능 플래그가 제거되었습니다.

병합 요청 승인 정책 비교 범위

  • 병합 요청 시 승인이 필요한지 확인하기 위해 각 지원되는 파이프라인 소스의 완료된 파이프라인을 소스 브랜치와 대상 브랜치(예: feature/main)에 대해 비교합니다. 이를 통해 스캔 결과를 가장 철저하게 평가할 수 있습니다.
  • 소스 브랜치의 비교 파이프라인은 소스 브랜치의 최신 커밋에 대해 각 지원되는 파이프라인 소스의 완료된 모든 파이프라인입니다.
  • 대상 브랜치의 경우 모든 공통 조상의 완료된 파이프라인을 각 지원되는 파이프라인 소스로 비교합니다.
  • 병합 요청 승인 정책은 승인이 필요한지를 결정할 때, 소스 브랜치와 대상 브랜치의 결과를 비교할 때 CI_PIPELINE_SOURCE 변수를 기반으로 모든 지원되는 파이프라인 소스(예: webide 및 parent_pipeline는 지원되지 않음)를 고려합니다.

미래 병합 요청에서 위험 수용 및 취약점 무시하기

newly_detected 결과에 대한 병합 요청 승인 정책에 대해, 이 취약점 상태의 영향을 이해하는 것이 중요합니다. 취약점은 병합 요청의 브랜치에는 있지만 기본 브랜치에는 없는 경우 newly_detected로 간주됩니다. 브랜치에 newly_detected 취약점이 포함된 병합 요청이 승인되고 병합되면, 승인자는 해당 취약점들의 “위험을 수용”합니다. 같은 취약점 중 하나 이상이 나중에 감지된 경우, 그 상태는 previously_detected로 간주되므로 newly_detected 취약점을 대상으로한 정책의 적용을 받지 않습니다.

예를 들어:

  • newly_detected SAST 취약점을 차단하기 위해 병합 요청 승인 정책이 생성되었습니다. 만약 CVE-1234에 대한 SAST 취약점이 승인되면, 동일한 위반을 가진 미래의 병합 요청은 프로젝트에서 승인이 필요하지 않습니다.

라이센스 승인 정책 사용 시, 프로젝트, 구성 요소(의존성) 및 라이선스의 조합이 평가됩니다. 라이센스가 예외로 승인되면, 미래의 병합 요청에서는 프로젝트, 구성 요소(의존성) 및 라이선스의 동일한 조합에 대해 승인이 필요하지 않습니다. 이 경우 구성 요소의 버전은 고려되지 않습니다. 예를 들어:

  • AGPL-1.0와 일치하는 신규 감지된 라이센스로 인해 병합 요청을 차단하기 위해 라이센스 승인 정책이 생성되었습니다. demo 프로젝트의 osframework에서 정책을 위반하는 변경이 이루어집니다. 이 변경이 승인되고 병합된 경우, 프로젝트 demo에서 osframework로의 미래의 병합 요청에 대해 AGPL-1.0 라이센스에 대한 승인이 필요하지 않습니다.

다중 승인

병합 요청 승인 정책은 추가 승인 단계가 필요한 여러 상황이 있습니다. 예를 들어:

  • 작업 브랜치에서 보안 작업 수가 감소하여 더 이상 대상 브랜치의 보안 작업 수와 일치하지 않습니다. 사용자는 CI/CD 구성에서 스캔 작업을 제거하여 스캔 결과 정책을 건너뛸 수 없습니다. 병합 요청 승인 정책 규칙에 구성된 보안 스캔만 제거 여부를 확인합니다.

    예를 들어, 기본 브랜치 파이프라인에는 sast, secret_detection, container_scanning, dependency_scanning 네 가지의 보안 스캔이 있습니다. 병합 요청 승인 정책은 container_scanning 및 dependency_scanning 두 개의 스캐너를 강제합니다. 만일 MR에서 병합 요청 승인 정책에 구성된 스캔을 제거한다면(ex. container_scanning), 추가 승인이 필요합니다.

  • 누군가 파이프라인 보안 작업을 중지하고, 사용자는 보안 스캔을 건너뛸 수 없습니다.
  • 병합 요청에서 작업이 실패하여 allow_failure: false로 구성되었습니다. 결과적으로 파이프라인이 차단된 상태가 됩니다.
  • 파이프라인에 전체 파이프라인을 통과하려면 반드시 성공해야 하는 수동 작업이 있습니다.

승인 요구를 평가하는 데 사용되는 스캔 결과 관리

병합 요청 승인 정책은 파이프라인이 완료된 후 파이프라인에서 생성된 아티팩트 보고서를 평가합니다. 병합 요청 승인 정책은 결과를 평가하고 스캔 결과를 기반으로 승인 여부를 결정하여 잠재적인 위험을 식별하고 병합 요청을 차단하고 승인을 요구합니다.

병합 요청 승인 정책은 그 이상의 범위로 확장되지 않습니다. 대신, 우리는 아티팩트 보고서의 결과를 신뢰합니다. 이를 통해 팀은 필요한 경우 스캔 실행 및 공급망을 관리하고 아티팩트 보고서에서 생성된 스캔 결과를 사용자 정의(예: 거짓 양성 필터링)할 수 있습니다.

예를 들어, lock 파일 변경은 보안 정책 관리의 범위를 벗어나지만 Code owners 또는 외부 상태 확인을 통해 완화할 수 있습니다. 자세한 정보는 issue 433029를 참조하세요.

스캔 결과 평가

알려진 문제점

우리는 승인이 필요한 스캔 결과에서 혼동이 발생하는 epic 11020을 식별했습니다. 아래는 몇 가지 알려진 문제점입니다:

  • newly_detected를 사용할 때 일부 결과가 병합 요청에서 도입되지 않았더라도(예: 관련 종속성의 새로운 CVE) 승인이 필요할 수 있습니다.
  • 병합 요청 승인 정책에서 승인이 필요하게 하는 결과 또는 오류가 보안 MR 위젯에 명확하게 표시되지 않을 수 있습니다. issue 428518에서 merge base가 도입됨으로써 일부 사례가 해결되었습니다. 보안 정책 위반의 원인에 대한 더 구체적인 세부 사항을 표시하도록 지원하는 것은 epic 11185에서 제안됩니다.
  • 보안 정책 위반은 MR 위젯에 표시되는 결과와는 다릅니다. 어떤 위반 사항은 MR 위젯에 표시되지 않을 수 있습니다. 우리는 epic 11020에서 기능을 조화롭게 만들고 epic 11185에서 병합 요청에서 정책 위반을 명시적으로 표시하는 데 노력하고 있습니다.
  • 프로젝트에 대한 병합 결과 파이프라인이 활성화되어 있고, 만들어진 MR에 대한 브랜치 파이프라인과 함께 사용될 때, 소스 및 대상 브랜치 간의 비교는 소스 브랜치의 파이프라인 완료 순서에 따라 달라집니다. 이는 issue 384927에서 제안된 해결책을 만들어내며, 선택된 대상 브랜치에 따라 승인이 다르게 작동할 수 있습니다.

실험적 기능

상태: 실험

보안 정책 범위

전제 조건:

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

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

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

저희 실험적 기능에 대한 피드백이 있으신가요? 의견을 주시면 감사하겠습니다! 저희 의견 문제에서 의견을 공유해 주세요.

보안 정책 시행은 보안 정책을 포함한 그룹, 하위 그룹 또는 프로젝트 간에 링크를 먼저 설정하는 것에 달려 있습니다. 예를 들어, 정책을 그룹에 링크하려면 그룹 소유자가 해당 보안 정책 프로젝트에 링크를 만들어야 합니다. 그런 다음, 보안 정책 프로젝트에 있는 모든 정책이 그룹 내의 모든 프로젝트에서 상속됩니다.

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

  • 규정 준수 프레임워크 레이블이 지정된 프로젝트만 포함합니다.
  • 선택한 프로젝트를 포함하거나 제외할 수 있습니다.

정책 범위 스키마

필드 유형 필수 가능한 값 설명
policy_scope object false compliance_frameworks, projects 컴플라이언스 프레임워크 레이블 또는 정의한 프로젝트를 기반으로 정책의 범위를 지정합니다.

policy_scope 범위 유형

필드 유형 가능한 값 설명
compliance_frameworks object ids 적용 범위 내의 컴플라이언스 프레임워크의 ID 목록으로, ids 배열에 포함됩니다.
projects object including, excluding excluding: 또는 including: 뒤에 포함하거나 제외하려는 프로젝트의 ID 목록을 나열합니다. ids 배열에 포함합니다.

보안 정책 범위를 사용한 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:
      ids:
      - 2
      - 11
    projects:
      including:
        ids:
        - 24
        - 27

Troubleshooting

병합 요청 규칙 위젯이 병합 요청 승인 정책이 잘못되었거나 중복되었다는 표시를 표시함

Tier: Ultimate Offering: Self-managed, GitLab Dedicated

15.0에서 16.4까지의 GitLab 자체 관리에서, 프로젝트가 그룹에서 내보내어 다른 곳으로 가져온 경우, 병합 요청 승인 정책 규칙이 있었을 가능성이 가장 높습니다. 이러한 규칙은 가져온 프로젝트와 별도의 프로젝트에 저장됩니다. 결과적으로 프로젝트에는 가져온 프로젝트 그룹에 존재하지 않는 엔터티를 참조하는 정책 규칙이 포함되어 있습니다. 결과적으로, 정책 규칙이 잘못되었거나 중복되었거나 둘 다인 경우가 있습니다.

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 가져오기
    [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|
  # 찾은 프로젝트 + ghost 구성 쌍마다, 주어진 프로젝트에 대해 이러한 규칙을 제거합니다
  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 사용자는 “병합 요청 승인 정책 디버깅”이라는 제목의 지원 티켓을 제출할 수 있습니다. 다음 세부 정보를 제공하세요.

  • 그룹 경로, 프로젝트 경로 및 선택적으로 병합 요청 ID
  • 심각도
  • 현재 동작
  • 예상 동작

지원팀은 로그(pubsub-sidekiq-inf-gprd*)를 조사하여 실패 reason을 식별합니다. 아래는 로그에서 예시 응답 스니펫입니다. 이 쿼리를 사용하여 승인 관련 로그를 찾을 수 있습니다: 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",
}

일반적인 실패 이유:

  • MR에 의해 스캐너 삭제: 병합 요청 승인 정책은 정책에서 정의된 스캐너가 존재하고 제대로 아티팩트를 생성하는 것을 기대합니다.