• 제한 사항
• 파이프라인 요구 사항
• 여러 파이프라인이 있는 병합 요청
• 병합 요청 승인 정책 편집기
• 병합 요청 승인 정책 스키마
• 병합 요청 승인 정책 스키마
• scan_finding 규칙 유형
• license_finding 규칙 유형
• any_merge_request 규칙 유형
• require_approval 작업 유형
• send_bot_message 작업 유형
  • 봇 메시지 예시
• approval_settings
• fallback_behavior
• 보안 정책 범위
  • 정책 범위 스키마
  • policy_scope 범위 유형
  • 예시 policy.yml 보안 정책 범위
• 예시 보안 병합 요청 승인 정책 프로젝트
• 병합 요청 승인 정책 승인을 이해하기
  • 병합 요청 승인 정책 비교 범위
  • 위험 수용 및 향후 병합 요청에서 취약점 무시하기
  • 여러 승인
  • 승인 요구 사항 평가에 사용되는 스캔 결과 관리
  • “Fix Available” 또는 “False Positive” 속성을 사용하여 정책 위반 필터링
• 문제 해결
  • 병합 요청 규칙 위젯이 유효하지 않거나 중복된 병합 요청 승인 정책을 표시합니다.
  • 새로 발견된 CVEs
  • policy.yml이 수동으로 무효화된 후에도 정책이 여전히 효과가 있음
  • 누락된 보안 스캔
  • 병합 요청 승인 정책 디버깅을 위한 지원 요청
    • GitLab.com
    • GitLab 자가 관리

병합 요청 승인 정책

• 그룹 수준의 스캔 결과 정책이 GitLab 15.6에서 도입되었습니다.
• 스캔 결과 정책 기능은 GitLab 16.9에서 병합 요청 승인 정책으로 이름이 변경되었습니다.

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

다음 비디오는 GitLab 병합 요청 승인 정책(이전의 스캔 결과 정책)에 대한 개요를 제공합니다:

제한 사항

• 병합 요청 승인 정책은 보호된 대상 브랜치에서만 적용할 수 있습니다.
• 각 정책에는 최대 5개의 규칙을 할당할 수 있습니다.
• 각 보안 정책 프로젝트에 최대 5개의 병합 요청 승인 정책을 할당할 수 있습니다.
• 그룹 또는 하위 그룹을 위해 생성된 정책은 그룹 내의 모든 병합 요청에 적용되는 데 시간이 걸릴 수 있습니다.
• 병합 요청 승인 정책은 아티팩트 보고서에서 생성된 스캔 결과의 무결성이나 진위성을 확인하지 않습니다.
• 병합 요청 승인 정책은 규칙에 따라 평가됩니다. 기본적으로 규칙이 유효하지 않거나 평가할 수 없을 경우 승인이 필요합니다. 이 동작은 fallback_behavior 필드를 사용하여 변경할 수 있습니다.

파이프라인 요구 사항

병합 요청 승인 정책은 파이프라인의 결과에 따라 적용됩니다. 병합 요청 승인 정책을 구현할 때 다음 사항을 고려하십시오:

• 병합 요청 승인 정책은 수동 작업을 무시하고 완료된 파이프라인 작업을 평가합니다. 수동 작업이 실행되면 정책은 병합 요청의 작업을 재평가합니다.
• 보안 스캐너의 결과를 평가하는 병합 요청 승인 정책은 모든 지정된 스캐너가 보안 보고서를 출력해야 합니다. 그렇지 않으면 취약점이 도입될 위험을 최소화하기 위해 승인이 필요합니다.
• 파이프라인은 소스와 대상 브랜치 모두에 대해 모든 활성화된 스캐너의 아티팩트를 생성해야 합니다. 그렇지 않으면 비교할 근거가 없으므로 정책을 평가할 수 없습니다. 이 요구 사항을 적용하기 위해 스캔 실행 정책을 사용해야 합니다.
• 정책 평가는 성공적이고 완료된 병합 기본 파이프라인에 따라 달라집니다. 병합 기본 파이프라인이 건너뛰어질 경우, 병합 요청은 병합 기본 파이프라인으로 차단됩니다.
• 정책에 지정된 보안 스캐너는 정책이 적용되는 프로젝트에서 구성되고 활성화되어야 합니다. 그렇지 않으면 병합 요청 승인 정책을 평가할 수 없으며 해당 승인이 필요합니다.

여러 파이프라인이 있는 병합 요청

• 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.com에서 활성화됨 GitLab 17.0에서.
• GitLab 17.1에서 일반적으로 사용 가능. 기능 플래그 approval_policy_parent_child_pipeline 제거됨.

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

• GitLab 16.3 및 이후 버전에서는 병합 요청의 소스 및 대상 브랜치에서 최신 커밋의 모든 완료된 파이프라인 결과가 평가되고 병합 요청 승인 정책을 시행하는 데 사용됩니다. 온디맨드 DAST 파이프라인은 고려되지 않습니다.
• GitLab 16.2 및 이전 버전에서는 병합 요청 승인 정책을 시행할 때 최신 완료된 파이프라인의 결과만 평가되었습니다.

프로젝트가 병합 요청 파이프라인을 사용하는 경우, 보안 스캔 작업이 파이프라인에 존재하도록 latest 보안 템플릿을 사용해야 합니다. 자세한 정보는 병합 요청 파이프라인과 함께 보안 스캔 도구 사용하기를 참조하세요.

병합 요청 승인 정책 편집기

• 기본적으로 활성화됨 GitLab 15.6에서.

참고: 오직 프로젝트 소유자만 권한을 가지고 보안 정책 프로젝트를 선택할 수 있습니다.

정책이 완료되면 편집기 하단에서 병합 요청과 함께 구성을 선택하여 저장하세요. 이것은 여러분을 프로젝트의 구성된 보안 정책 프로젝트의 병합 요청으로 리디렉션합니다. 보안 정책 프로젝트가 여러분의 프로젝트에 연결되어 있지 않으면, GitLab이 그런 프로젝트를 생성합니다. 기존 정책은 편집기 인터페이스에서 정책 삭제를 선택하여 제거할 수도 있습니다.

대부분의 정책 변경 사항은 병합 요청이 병합되면 즉시 적용됩니다. 병합 요청을 거치지 않고 기본 브랜치에 직접 커밋된任何 변경 사항은 정책 변경 사항이 적용되기까지 최대 10분이 걸릴 수 있습니다.

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

참고: 대량의 프로젝트가 있는 그룹에 대해 생성된 병합 요청 승인 정책을 전파하는 데는 다소 시간이 걸립니다.

병합 요청 승인 정책 스키마

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

참고: 병합 요청 승인 정책은 scan_result_policy 키 아래에 정의되었습니다. GitLab 17.0까지 정책은 두 키 아래에서 정의될 수 있습니다. GitLab 17.0부터는 오직 approval_policy 키만 지원됩니다.

새로운 정책을 저장할 때 GitLab은 이 JSON 스키마에 대해 내용을 검증합니다. JSON 스키마 읽는 방법을 모르시면, 다음 섹션과 표가 대안을 제공합니다.

병합 요청 승인 정책 스키마

• 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 규칙 유형

• 병합 요청 승인 정책 필드 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 옵션이 추가되었습니다.

이 규칙은 보안 스캔 결과에 따라 정의된 작업을 시행합니다.

license_finding 규칙 유형

• 도입됨 GitLab 15.9에서 license_scanning_policies라는 플래그와 함께.
• GitLab 15.11에서 일반 사용 가능. 기능 플래그 license_scanning_policies 제거됨.
• branch_exceptions 필드는 GitLab 16.3에서 도입됨 security_policies_branch_exceptions라는 플래그와 함께. 기본적으로 활성화됨. GitLab 16.5에서 일반 사용 가능. 기능 플래그 제거됨.

이 규칙은 라이센스 발견에 따라 정의된 작업을 시행합니다.

any_merge_request 규칙 유형

• branch_exceptions 필드는 GitLab 16.3에서 도입됨 security_policies_branch_exceptions라는 플래그와 함께. 기본적으로 활성화됨. GitLab 16.5에서 일반 사용 가능. 기능 플래그 제거됨.
• any_merge_request 규칙 유형은 GitLab 16.4에서 도입됨. 기본적으로 활성화됨. GitLab 16.6에서 일반 사용 가능. 기능 플래그 제거됨.

이 규칙은 커밋 서명에 따라 모든 병합 요청에 대해 정의된 작업을 시행합니다.

require_approval 작업 유형

이 작업은 정의된 정책에서 하나 이상의 규칙에 대해 조건이 충족될 때 승인이 필요하도록 승인 규칙을 설정합니다.

send_bot_message 작업 유형

• send_bot_message 작업 유형은 GitLab 16.11에서 프로젝트용으로 도입되었습니다 플래그인 approval_policy_disable_bot_comment와 함께. 기본적으로 비활성화되어 있습니다.
• GitLab 17.0에서 자체 관리 및 GitLab 전용으로 활성화되었습니다.
• GitLab 17.3에서 일반적으로 사용 가능. 기능 플래그 approval_policy_disable_bot_comment가 제거되었습니다.
• send_bot_message 작업 유형은 GitLab 17.2에서 그룹용으로 도입되었습니다 플래그인 approval_policy_disable_bot_comment_group와 함께. 기본적으로 비활성화되어 있습니다.
• GitLab 17.2에서 자체 관리 및 GitLab 전용으로 활성화되었습니다.
• GitLab 17.3에서 일반적으로 사용 가능. 기능 플래그 approval_policy_disable_bot_comment_group가 제거되었습니다.

이 작업은 정책 위반이 감지될 때 병합 요청에서 봇 메시지를 구성할 수 있도록 합니다.

작업이 지정되지 않으면 기본적으로 봇 메시지가 활성화됩니다. 정의된 정책이 여러 개일 경우, 이러한 정책 중 하나에 send_bot_message 작업이 활성화된 경우 봇 메시지가 전송됩니다.

봇 메시지 예시

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.com에서 GitLab 16.7에 활성화되었습니다.
• 위 필드는 Self-Managed에서 GitLab 16.7에 활성화되었습니다.
• 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.com에서 GitLab 16.6에 활성화되었습니다.
• 위 필드는 Self-Managed에서 GitLab 16.7에 활성화되었습니다.
• 기능 플래그 scan_result_any_merge_request는 GitLab 16.8에서 제거되었습니다.
• prevent_pushing_and_force_pushing 필드는 GitLab 16.4에서 scan_result_policies_block_force_push라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• 위 필드는 GitLab.com에서 GitLab 16.6에 활성화되었습니다.
• 위 필드는 Self-Managed에서 GitLab 16.7에 활성화되었습니다.
• 기능 플래그 scan_result_policies_block_force_push는 GitLab 16.8에서 제거되었습니다.

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

fallback_behavior

• fallback_behavior 필드는 GitLab 17.0에서 도입되었습니다 플래그와 함께 security_scan_result_policies_unblock_fail_open_approval_rules라는 이름으로. 기본적으로 비활성화되어 있습니다.
• fallback_behavior 필드는 GitLab.com, self-managed, 및 GitLab Dedicated에서 활성화되었습니다 GitLab 17.0에서.

보안 정책 범위

• GitLab 16.7에서 도입되었습니다 플래그와 함께 security_policies_policy_scope. 기본적으로 활성화되어 있습니다.
• GitLab 16.11에서 일반 제공. 기능 플래그 security_policies_policy_scope가 제거되었습니다.
• 그룹에 의한 범위 지정 GitLab 17.4에서 도입되었습니다.

보안 정책 집행은 먼저 정책을 집행하고자 하는 그룹, 하위 그룹 또는 프로젝트와 해당 정책을 포함하는 보안 정책 프로젝트 간의 링크를 설정하는 데 의존합니다. 예를 들어, 정책을 그룹에 연결하는 경우 그룹 소유자는 보안 정책 프로젝트에 대한 링크를 생성해야 합니다. 그런 다음 보안 정책 프로젝트의 모든 정책은 그룹 내의 모든 프로젝트에 상속됩니다.

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

• 포함 하기: 규정 준수 프레임워크 레이블이 포함된 프로젝트만.
• 포함 또는 제외 하기: 집행에서 선택한 프로젝트.
• 포함 하기: 선택한 그룹. 선택적으로 이와 함께 projects 객체를 사용하여 선택된 프로젝트를 제외할 수 있습니다.

정책 범위 스키마

policy_scope 범위 유형

예시 policy.yml 보안 정책 범위

---
approval_policy:
- name: 치명적인 취약점 CS 승인
  description: 컨테이너 스캐닝을 위한 치명적인 심각도 수준만 해당
  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: 치명적인 취약점 CS 승인
  description: 컨테이너 스캐닝을 위한 치명적인 심각도 수준만 해당
  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: 2차 CS 승인
  description: 컨테이너 스캐닝을 위한 2차 전용
  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 역할을 가진 프로젝트 구성원으로부터 하나의 승인을 요구합니다.

병합 요청 승인 정책 승인을 이해하기

• scan_finding의 브랜치 비교 로직은 GitLab 16.8에서 변경되었습니다 플래그 이름은 scan_result_policy_merge_base_pipeline입니다. 기본적으로 비활성화되어 있습니다.
• GitLab 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 소스의 파이프라인은 지원되지 않습니다.
• GitLab 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과 일치하는 병합 요청을 차단하기 위해 라이센스 승인 정책이 생성됩니다. 정책을 위반하는 osframework 구성 요소에 대한 프로젝트 demo에서 변경이 이루어집니다. 승인되고 병합되면, 프로젝트 demo의 osframework에 대한 향후 병합 요청은 라이센스 AGPL-1.0에 대해 승인이 필요하지 않습니다.

여러 승인

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

• 작업 브랜치의 보안 작업 수가 줄어들고 더 이상 대상 브랜치의 보안 작업 수와 일치하지 않습니다. 사용자들은 CI/CD 구성에서 스캔 작업을 제거하여 스캐닝 결과 정책을 생략할 수 없습니다. 병합 요청 승인 정책 규칙에 구성된 보안 스캔만 제거 여부를 확인합니다.

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

• 누군가 파이프라인 보안 작업을 중지하고 사용자는 보안 스캔을 생략할 수 없습니다.
• 병합 요청의 작업이 실패하고 allow_failure: false로 구성됩니다. 결과적으로 파이프라인이 차단 상태입니다.
• 파이프라인에 전체 파이프라인을 통과하기 위해 성공적으로 실행해야 하는 수동 작업이 있습니다.

승인 요구 사항 평가에 사용되는 스캔 결과 관리

병합 요청 승인 정책은 파이프라인이 완료된 후 스캐너가 생성한 아티팩트 보고서를 평가합니다. 병합 요청 승인 정책은 결과 평가에 중점을 두고 있으며, 스캔 결과 발견에 따라 잠재적 위험을 식별하고, 병합 요청을 차단하며, 승인을 요구합니다.

병합 요청 승인 정책은 아티팩트 파일이나 스캐너에 접근하는 범위를 넘어 확장되지 않습니다. 대신, 우리는 아티팩트 보고서의 결과를 신뢰합니다. 이는 팀이 스캔 실행 및 공급망 관리에서 유연성을 제공하고 필요에 따라 아티팩트 보고서에서 생성된 스캔 결과를 사용자화할 수 있도록 합니다(예: 잘못된 긍정 결과를 필터링).

잠금 파일 변조는 보안 정책 관리의 범위를 벗어나는 예시지만, 코드 소유자 또는 외부 상태 확인을 통해 완화될 수 있습니다. 자세한 내용은 문제 433029를 참조하세요.

“Fix Available” 또는 “False Positive” 속성을 사용하여 정책 위반 필터링

불필요한 승인 요구 사항을 피하기 위해, 이러한 추가 필터는 가장 실행 가능한 발견 사항에 대해서만 MRs를 차단하도록 돕습니다.

YAML에서 fix_available을 false로 설정하거나 정책 편집기에서 is not 및 Fix Available로 설정하면, 해결책이나 수정이 가능한 경우 발견 사항은 정책 위반으로 간주되지 않습니다. 해결책은 취약성 객체의 Solution 제목 아래에 나타납니다. 수정 사항은 취약성 객체 내에 Resolve with Merge Request 버튼으로 나타납니다.

Resolve with Merge Request 버튼은 아래의 기준 중 하나가 충족될 때만 나타납니다:

1. Ultimate Tier에 있으며 GitLab Duo Enterprise가 있는 프로젝트에서 SAST 취약성이 발견됩니다.

2. GIT_STRATEGY: fetch가 설정된 작업에서 Ultimate Tier에 있는 프로젝트에서 컨테이너 스캔 취약성이 발견됩니다. 추가적으로, 취약성은 컨테이너 이미지에 대해 활성화된 저장소에 대한 수정이 포함된 패키지가 있어야 합니다.

3. yarn으로 관리되는 Node.js 프로젝트에서 의존성 스캔 취약성이 발견되고 수정 사항이 제공됩니다. 추가적으로, 프로젝트는 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|  
    # 적합한 프로젝트 규칙에 대한 프로젝트 및 configuration_ids 가져오기  
    [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| # 프로젝트 + configuration_ids의 고유한 조합만 가져옵니다.  
    # 프로젝트에 대해 사용 가능한 구성보다 더 많은 구성을 찾으면 추가 구성으로 기록을 가져옵니다.  
    [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  

새로 발견된 CVEs

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 사용자들은 “Merge request approval policy debugging”이라는 제목의 지원 티켓을 제출할 수 있습니다. 다음 세부정보를 제공하십시오:

• 그룹 경로, 프로젝트 경로 및 선택적으로 병합 요청 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 자가 관리

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

일반적인 실패 이유:

• MR에 의해 제거된 스캐너: 병합 요청 승인 정책은 정책에 정의된 스캐너가 존재해야 하며 비교를 위해 성공적으로 아티팩트를 생성해야 한다고 기대합니다.