• 요구 사항 및 제한 사항
• 여러 파이프라인을 사용하는 Merge Request
• Merge Request 승인 정책 편집기
• Merge Request 승인 정책 스키마
• Merge Request 승인 정책 스키마
• scan_finding 규칙 유형
• license_finding rule type
• any_merge_request rule type
• require_approval action type
• approval_settings
• 보안 Merge Request 승인 정책 프로젝트 예시
• Merge Request 승인 정책 편집기 예시
• Merge Request 승인 정책 승인 범위 이해
  • Merge Request 승인 정책 비교 범위
  • 미래 Merge Request에서의 위험 수용 및 취약점 무시
  • 다중 승인
  • 승인 요구 사항을 평가하는 머지 요청 승인 정책
  • 알려진 이슈
• 실험적인 기능
  • 보안 정책 범위
    • 정책 범위 스키마
    • policy_scope 범위 유형
    • 보안 정책 스코프가 있는 policy.yml의 예
• 문제 해결
  • 머지 요청 규칙 위젯이 머지 요청 승인 정책이 잘못되었거나 중복되었다는 것을 보여줍니다
  • 디버깅 보안 승인 정책 승인

Merge Request 승인 정책 (이전: 스캔 결과 정책)

• GitLab 15.6에서 도입된 그룹 레벨 스캔 결과 정책 소개.
• 스캔 결과 정책 기능은 GitLab 16.9에서 Merge Request 승인 정책으로 이름이 변경되었습니다.

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

다음 비디오에서는 GitLab Merge Request 승인 정책(이전 스캔 결과 정책)에 대한 개요를 제공합니다.

요구 사항 및 제한 사항

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

여러 파이프라인을 사용하는 Merge Request

• GitLab 16.2에서 도입되었으며 기본적으로 비활성화된 multi_pipeline_scan_result_policies 플래그로 제공되었습니다.
• GitLab 16.3에서 일반 사용 가능하며 multi_pipeline_scan_result_policies 플래그가 제거되었습니다.

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

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

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

Merge Request 승인 정책 편집기

• GitLab 14.8에서 도입되었습니다.
• GitLab 15.6에서 기본적으로 활성화되었습니다.

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

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

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

Merge Request 승인 정책 스키마

Merge Request 승인 정책이 포함된 YAML 파일은 approval_policy 키 하위에 중첩된 Merge Request 승인 정책 스키마의 배열로 구성됩니다. approval_policy 키 하에 최대 5개의 정책을 구성할 수 있습니다.

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

Merge Request 승인 정책 스키마

• approval_settings 필드는 GitLab 16.4에서 도입되었으며 scan_result_policies_block_unprotecting_branches, scan_result_any_merge_request, 또는 scan_result_policies_block_force_push와 같은 플래그가 부여되었습니다. 자세한 내용은 아래의 approval_settings 섹션을 참조하십시오.

scan_finding 규칙 유형

• Merge Request 승인 정책 필드 vulnerability_attributes는 GitLab 16.2에서 도입되었으며 enforce_vulnerability_attributes_rules와 같은 플래그로 일반 사용 가능하게 되었습니다. 플래그는 삭제되었습니다.
• Merge Request 승인 정책 필드 vulnerability_age는 GitLab 16.2에서 도입되었습니다.
• branch_exceptions 필드는 GitLab 16.3에서 도입되었으며 security_policies_branch_exceptions와 같은 플래그로 일반 사용 가능하게 되었습니다. 플래그는 삭제되었습니다.

이 규칙은 보안 스캔 결과에 기반하여 정의된 작업을 강제합니다.

license_finding rule type

이 규칙은 라이선스 발견에 기반하여 정의된 작업을 강제합니다.

any_merge_request rule type

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

require_approval action type

이 작업은 정의된 정책의 적어도 하나의 규칙이 충족되면 승인 규칙이 필요하도록 설정합니다.

approval_settings

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

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

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

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은 소유자 역할을 하는 프로젝트 구성원으로부터의 승인이 필요합니다.

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에서 일반적으로 사용 가능합니다. scan_result_policy_merge_base_pipeline 피처 플래그가 제거되었습니다.

Merge Request 승인 정책 비교 범위

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

미래 Merge Request에서의 위험 수용 및 취약점 무시

newly_detected 결과로 범위를 지정한 Merge Request 승인 정책의 경우, 취약성 상태의 영향을 이해하는 것이 중요합니다. 취약점이 Merge Request 브랜치에 존재하지만 기본 브랜치에는 존재하지 않으면 취약점은 newly_detected로 간주됩니다. Merge Request의 브랜치에 newly_detected 취약점을 포함하고 승인 및 Merge되면, 승인자는 해당 취약점들의 “위험을 수용”합니다. 이후 동일한 취약점들 중 하나 이상이 감지될 경우, 그 상태는 previously_detected이므로 newly_detected 취약점을 대상으로 한 정책의 적용 범위에 해당하지 않습니다. 예시:

• CVE-1234에 대한 SAST 취약성을 차단하는 Merge Request 승인 정책이 생성됩니다. 만약 CVE-1234의 SAST 취약점이 승인된다면, 동일한 위반을 갖는 미래 Merge Request은 프로젝트에서 승인이 필요하지 않습니다.

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

• AGPL-1.0와 일치하는 새로운 라이선스를 차단하는 라이선스 승인 정책이 생성됩니다. demo 프로젝트에 대해 osframework 컴포넌트에서 정책을 위반하는 변경이 발생한다면, 승인 및 Merge된 후에 demo 프로젝트의 osframework에 대한 AGPL-1.0 라이선스를 갖는 미래의 Merge Request에 대해 승인이 필요하지 않습니다.

다중 승인

Merge Request 승인 정책에서 추가 승인 단계가 필요한 여러 상황이 있습니다. 예시:

• 작업 브랜치의 보안 작업 수가 감소되어 더 이상 대상 브랜치의 보안 작업 수와 일치하지 않는 경우, 사용자는 CI/CD 구성에서 스캔 작업을 제거함으로써 스캔 결과 정책을 건너뛸 수 없습니다. Merge Request 승인 정책은 container_scanning과 dependency_scanning 두 스캐너를 강제하기 때문에, 예를 들어 기본 브랜치 파이프라인에는 sast, secret_detection, container_scanning, dependency_scanning 네 가지 보안 스캔이 있고, Merge Request 승인 정책이 container_scanning 스캐너를 강제한다면, container_scanning이 제거된 경우 추가 승인이 필요합니다.
• 누군가가 파이프라인 보안 작업을 중지하고, 사용자는 보안 스캔을 건너뛸 수 없습니다.
• Merge Request에서 작업이 실패하고 allow_failure: false로 구성된 경우, 파이프라인이 차단된 상태가 됩니다.
• 파이프라인에는 전체 파이프라인의 성공에 필요한 매뉴얼 작업이 있어야 합니다.

승인 요구 사항을 평가하는 머지 요청 승인 정책

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

머지 요청 승인 정책은 아티패트 파일이나 스캐너로 확장되지는 않습니다. 대신, 우리는 아티팩트 보고서의 결과를 신뢰합니다. 이는 팀이 필요한 경우 스캔 실행 및 공급망을 관리하고, 스캔 결과를 사용자 정의할 수 있도록 합니다(예: 가짜 양성 결과 필터링).

예를 들어, 락 파일 조작은 보안 정책 관리 범위를 벗어나지만 Code owners나 external status checks를 사용하여 완화될 수 있습니다. 더 많은 정보는 issue 433029를 참조하세요.

알려진 이슈

스캔 결과에 대한 혼동의 일반적인 영역을 식별했습니다 epic 11020. 아래는 알려진 이슈 중 일부입니다:

• newly_detected를 사용하는 경우 일부 결과는 머지 요청에서 도입되지 않았음에도 승인이 필요할 수 있습니다(예: 관련 의존성의 새로운 CVE).
• 머지 요청 승인 정책에서 승인을 필요로 하는 결과나 오류가 보안 MR 위젯에 명확하게 표시되지 않을 수 있습니다. issue 428518에서 merge base가 도입되어 일부 사례가 해결되었습니다. 더 많은 세부 정보를 보여주는 기능에 대한 지원은 epic 11185에서 제안됩니다.
• 보안 정책 위반은 MR 위젯에 표시되는 결과와는 다릅니다. 어떤 위반 사항은 MR 위젯에 표시되지 않을 수 있습니다. 우리는 우리의 기능을 조화롭게 만들고 epic 11020에서 정책 위반을 명시적으로 머지 요청에 표시하기 위해 노력하고 있습니다.
• 프로젝트에 대한 머지된 결과 파이프라인과 생성된 MRs에 대한 브랜치 파이프라인이 모두 활성화된 경우, 소스 브랜치의 파이프라인이 완료된 순서에 따라 소스와 대상 브랜치의 비교가 달라집니다. 이는 issue 384927에서 제안된 해결 방법에 따라, 승인이 다르게 작동할 수 있습니다.

실험적인 기능

보안 정책 범위

전제 조건:

• 이러한 실험적인 기능을 활성화하려면 그룹 소유자 또는 관리자가 실험적인 기능을 활성화해야 합니다.
  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
  2. Settings > General을 선택합니다.
  3. Permissions and group features를 확장합니다.
  4. Security Policy Scopes 확인란을 선택합니다.

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

     하위 그룹에 대한 설정이 강제 적용되지 않은 경우, 하위 그룹 소유자가 설정을 개별적으로 관리할 수 있습니다.

우리 실험적인 기능에 대한 피드백이 있으십니까? 의견을 주시면 감사하겠습니다! 아래의 피드백 issue에서 의견을 공유해주세요.

보안 정책 강제 실행은 먼저 보안 정책을 포함하는 그룹, 하위 그룹 또는 프로젝트와 보안 정책을 포함하는 보안 정책 프로젝트 사이의 링크를 설정하는 것에 의존합니다. 예를 들어, 그룹에 정책을 링크하려면 그룹 소유자가 보안 정책 프로젝트에 대한 링크를 작성해야 합니다. 그럼 모든 보안 정책 프로젝트의 정책이 그룹의 모든 프로젝트에 상속됩니다.

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

• 규정 준수 프레임워크 라벨이 포함된 프로젝트만을 포함합니다.
• 선택한 프로젝트를 강제 적용하거나 제외합니다.

정책 범위 스키마

policy_scope 범위 유형

보안 정책 스코프가 있는 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

문제 해결

머지 요청 규칙 위젯이 머지 요청 승인 정책이 잘못되었거나 중복되었다는 것을 보여줍니다

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

GitLab 인스턴스에서 모든 잘못된 머지 요청 승인 정책 규칙을 제거하려면, 관리자는 Rails console에서 다음 스크립트를 실행할 수 있습니다.

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|
    # Get projects and their configuration_ids for applicable project rules
    [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| # We take only unique combinations of project + configuration_ids
    # If we find more configurations than what is available for the project, we take records with the extra 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|
  # For each found pair project + ghost configuration, we remove these rules for a given project
  Security::OrchestrationPolicyConfiguration.where(id: configuration_ids).each do |configuration|
    configuration.delete_scan_finding_rules_for_project(project.id)
  end
  # Ensure we sync any potential rules from new group's policy
  Security::ScanResultPolicies::SyncProjectWorker.perform_async(project.id)
end

디버깅 보안 승인 정책 승인

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

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

지원 팀은 로그 (pubsub-sidekiq-inf-gprd*)를 조사하여 실패 ‘이유’를 식별할 것입니다. 아래는 로그에서의 예시 응답 조각입니다. 이 쿼리를 사용하여 승인과 관련된 로그를 찾을 수 있습니다: json.event.keyword: "update_approvals" 및 json.project_path: "group-path/project-path". 선택적으로, json.merge_request_iid를 사용하여 Merge Request 식별자를 추가로 필터링할 수 있습니다:

"json": {
  "project_path": "group-path/project-path",
  "merge_request_iid": 2,
  "missing_scans": [
    "api_fuzzing"
  ],
  "reason": "Scanner removed by MR",
  "event": "update_approvals",
}

일반적인 실패 이유:

• Scanner removed by MR: Merge Request 승인 정책은 정책에 정의된 스캐너가 존재하고, 비교를 위해 성공적으로 artifact를 생성했음을 예상합니다.