히스토리

• 스캔 실행 정책 편집기에서 사용자 정의 CI/CD 변수 지원이 GitLab 16.2에서 도입됨.
• 기존 GitLab CI/CD 구성이 있는 프로젝트에서 스캔 실행 정책 적용이 GitLab 16.2에서 scan_execution_policy_pipelines라는 플래그와 함께 도입됨. 기능 플래그 scan_execution_policy_pipelines이 GitLab 16.5에서 제거됨.
• 스캔 실행 정책에서 미리 정의된 변수 재정의가 GitLab 16.10에서 allow_restricted_variables_at_policy_level이라는 플래그와 함께 도입됨. 기본적으로 활성화됨. 기능 플래그 allow_restricted_variables_at_policy_level이 GitLab 17.5에서 제거됨.

스캔 실행 정책은 기본 또는 최신 보안 CI/CD 템플릿을 기반으로 GitLab 보안 스캔을 강제합니다. 파이프라인의 일부로 또는 지정된 일정에 따라 스캔 실행 정책을 배포할 수 있습니다.

스캔 실행 정책은 보안 정책 프로젝트에 연결된 모든 프로젝트에 보안 스캔을 강제합니다. .gitlab-ci.yml 파일이 없는 프로젝트 또는 AutoDevOps가 비활성화된 프로젝트의 경우 보안 정책은 .gitlab-ci.yml 파일을 암시적으로 생성합니다. .gitlab-ci.yml 파일은 시크릿 탐지, 정적 분석 또는 프로젝트에서 빌드가 필요하지 않은 다른 스캐너를 실행하는 정책이 항상 실행되고 강제될 수 있도록 합니다.

스캔 실행 정책과 파이프라인 실행 정책 모두 보안 및 컴플라이언스를 관리하기 위해 여러 프로젝트에 걸쳐 GitLab 보안 스캔을 구성할 수 있습니다. 스캔 실행 정책은 더 빠르게 구성할 수 있지만 사용자 정의가 불가능합니다. 다음 중 하나가 해당되는 경우 파이프라인 실행 정책을 대신 사용하세요:

• 고급 구성 설정이 필요한 경우.
• 사용자 정의 CI/CD 작업이나 스크립트를 강제하려는 경우.
• 강제된 CI/CD 작업을 통해 서드파티 보안 스캔을 활성화하려는 경우.

스캔 실행 정책 생성#

스캔 실행 정책을 생성하려면 다음 리소스를 사용할 수 있습니다:

• 동영상 안내는 GitLab에서 보안 스캔 정책 설정 방법을 참조하세요.
• GitLab CI/CD 구성이 없는 프로젝트에 스캔 실행 정책 강제에 대해 알아보세요.
• 스캔 실행 정책 생성 방법은 튜토리얼: 스캔 실행 정책 설정을 참조하세요.

제한 사항#

• 각 정책에 최대 5개의 규칙을 할당할 수 있습니다.
• 각 보안 정책 프로젝트에 최대 5개의 스캔 실행 정책을 할당할 수 있습니다.
• 로컬 프로젝트 YAML 파일은 스캔 실행 정책을 재정의할 수 없습니다. 스캔 실행 정책은 프로젝트의 CI/CD 구성에서 동일한 작업 이름을 사용하더라도 파이프라인에 정의된 모든 구성보다 우선합니다.
• 예약된 정책(type: schedule)은 예약된 cadence에 따라서만 실행됩니다. 정책을 업데이트해도 즉각적인 스캔이 트리거되지 않습니다.
• YAML 구성 파일에 직접 커밋하거나 푸시하여(정책 편집기 대신) 정책을 업데이트하는 경우 시스템을 통해 전파되는 데 최대 10분이 걸릴 수 있습니다. (이 제한에 대한 제안된 변경 사항은 이슈 512615를 참조하세요.)

작업 스테이지#

DAST 스캔은 항상 dast 스테이지에서 실행됩니다. dast 스테이지가 없으면 GitLab은 파이프라인 끝에 dast 스테이지를 삽입합니다.

다른 모든 스캔에 대한 정책 작업은 파이프라인의 test 스테이지에서 실행됩니다. 기본 파이프라인에서 test 스테이지를 제거하면 다음 규칙에 따라 작업이 대신 scan-policies 스테이지에서 실행됩니다:

• scan-policies 스테이지가 아직 존재하지 않으면 GitLab이 평가 시점에 CI/CD 파이프라인에 스테이지를 삽입합니다.
• build 스테이지가 있으면 GitLab이 build 스테이지 바로 다음에 scan-policies를 삽입합니다.
• build 스테이지가 없으면 GitLab이 파이프라인 시작 부분에 scan-policies를 삽입합니다.

작업 이름 충돌을 방지하기 위해 작업 이름에 하이픈과 숫자가 추가됩니다. 각 숫자는 각 정책 작업에 대한 고유한 값입니다. 예를 들어 secret-detection은 secret-detection-1이 됩니다.

스캔 실행 정책 편집기#

히스토리

• Merge Request Security Template:
• GitLab 18.2에서 flexible_scan_execution이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.
• GitLab 18.3에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화됨.
• GitLab 18.4에서 일반 가용성. 기능 플래그 flexible_scan_execution 제거됨.

스캔 실행 정책 편집기를 사용하여 스캔 실행 정책을 생성하거나 편집합니다.

사전 요구사항:

• 기본적으로 그룹, 하위 그룹 또는 프로젝트 Owner만 보안 정책 프로젝트를 생성하거나 할당하는 데 필요한 권한을 가집니다. 또는 보안 정책 링크 관리 권한을 가진 사용자 정의 역할을 생성할 수 있습니다.

첫 번째 스캔 실행 정책을 생성할 때 일반적인 사용 사례에 대한 다음 템플릿에서 선택합니다:

• Merge Request Security
  • 사용 사례: 모든 커밋이 아닌 머지 리퀘스트가 생성될 때만 보안 스캔을 실행하려는 경우.
  • 사용 시기: 기본 또는 보호된 브랜치를 대상으로 하는 소스 브랜치에서 보안 스캔을 실행해야 하는 머지 리퀘스트 파이프라인을 사용하는 프로젝트.
  • 최적: 머지 리퀘스트 승인 정책에 맞추고 모든 브랜치에서 스캔을 피함으로써 인프라 비용 절감.
  • 파이프라인 소스: 주로 머지 리퀘스트 파이프라인.
• Scheduled Scanning
  • 사용 사례: 코드 변경에 관계없이 일정(예: 일별 또는 주별)에 따라 자동으로 보안 스캔을 실행하려는 경우.
  • 사용 시기: 개발 활동에 독립적인 정기적인 주기로 보안 스캔.
  • 최적: 컴플라이언스 요구사항, 기준 보안 모니터링 또는 커밋 빈도가 낮은 프로젝트.
  • 파이프라인 소스: 예약된 파이프라인.
• Release Security
  • 사용 사례: main 또는 릴리스 브랜치의 모든 변경 사항에서 보안 스캔을 실행하려는 경우.
  • 사용 시기: 릴리스 전에 포괄적인 스캔이 필요한 프로젝트 또는 보호된 브랜치.
  • 최적: 릴리스 게이트 워크플로우, 프로덕션 배포 또는 고보안 환경.
  • 파이프라인 소스: 보호된 브랜치에 대한 푸시 파이프라인, 릴리스 파이프라인.

사용 가능한 템플릿이 요구사항을 충족하지 않거나 더 사용자 정의된 스캔 실행 정책이 필요한 경우:

• 사용자 정의 옵션을 선택하고 사용자 정의 요구사항으로 스캔 실행 정책을 생성합니다.
• 파이프라인 실행 정책을 사용하여 보안 스캔 및 CI 강제에 대한 더 사용자 정의 가능한 옵션에 액세스합니다.

정책이 완료되면 편집기 하단의 머지 리퀘스트로 구성을 선택하여 정책을 저장합니다. 프로젝트의 구성된 보안 정책 프로젝트의 머지 리퀘스트로 리디렉션됩니다. 보안 정책 프로젝트가 프로젝트에 연결되지 않은 경우 GitLab이 자동으로 생성합니다. 편집기 인터페이스에서 편집기 하단의 정책 삭제를 선택하여 기존 정책을 제거할 수 있습니다. 이 작업은 policy.yml 파일에서 정책을 제거하는 머지 리퀘스트를 생성합니다.

대부분의 정책 변경 사항은 머지 리퀘스트가 병합되는 즉시 적용됩니다. 머지 리퀘스트 대신 기본 브랜치에 직접 커밋된 변경 사항은 정책 변경 사항이 적용되기까지 최대 10분이 필요합니다.

스캔 실행 정책 스키마#

스캔 실행 정책이 있는 YAML 구성은 스캔 실행 정책 스키마와 일치하는 객체 배열로 구성됩니다. 객체는 scan_execution_policy 키 아래에 중첩됩니다. scan_execution_policy 키 아래에 최대 5개의 정책을 구성할 수 있습니다. 처음 5개 이후에 구성된 다른 정책은 적용되지 않습니다.

새 정책을 저장하면 GitLab이 이 JSON 스키마에 대해 정책의 내용을 검증합니다. JSON 스키마에 익숙하지 않은 경우 다음 섹션과 표가 대안을 제공합니다.

스캔 실행 정책 스키마#

히스토리

• 정책당 작업 제한이 GitLab 17.4에서 scan_execution_policy_action_limit(프로젝트용) 및 scan_execution_policy_action_limit_group(그룹용)이라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.
• 정책당 작업 제한이 GitLab 18.0에서 일반 가용성. 기능 플래그 scan_execution_policy_action_limit(프로젝트용) 및 scan_execution_policy_action_limit_group(그룹용) 제거됨.

skip_ci 유형#

히스토리

• GitLab 17.9에서 도입됨.

스캔 실행 정책은 [skip ci] 지시문을 사용할 수 있는 사람을 제어합니다. 중요한 보안 및 컴플라이언스 검사가 수행되도록 하면서 [skip ci]를 사용할 수 있는 특정 사용자 또는 서비스 계정을 지정할 수 있습니다.

skip_ci 키워드를 사용하여 사용자가 파이프라인을 건너뛰기 위해 skip_ci 지시문을 적용할 수 있는지 여부를 지정합니다. 키워드가 지정되지 않으면 skip_ci 지시문이 무시되어 모든 사용자가 파이프라인 실행 정책을 우회하는 것을 방지합니다.

pipeline 규칙 유형#

히스토리

• branch_type 필드:
• GitLab 16.1에서 security_policies_branch_type이라는 플래그와 함께 도입됨.
• GitLab 16.2에서 일반 가용성. 기능 플래그 security_policies_branch_type 제거됨.
• branch_exceptions 필드:
• GitLab 16.3에서 security_policies_branch_exceptions라는 플래그와 함께 도입됨.
• GitLab 16.5에서 일반 가용성. 기능 플래그 security_policies_branch_exceptions 제거됨.
• pipeline_sources 필드와 branch_type 옵션 target_default 및 target_protected:
• GitLab 18.2에서 flexible_scan_execution이라는 플래그와 함께 도입됨.
• GitLab 18.3에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화됨.
• GitLab 18.4에서 일반 가용성. 기능 플래그 flexible_scan_execution 제거됨.

이 규칙은 파이프라인이 선택한 브랜치에 대해 실행될 때마다 정의된 작업을 강제합니다.

1. branches 또는 branch_type 중 하나를 지정해야 하지만 둘 다는 안됩니다.
2. 일부 옵션은 flexible_scan_execution 기능 플래그가 활성화된 경우에만 사용할 수 있습니다. 자세한 내용은 이력을 참조하세요.
3. branch_type 옵션 target_default 또는 target_protected가 지정된 경우 pipeline_sources 필드는 merge_request_event 및 push 필드만 지원합니다.

schedule 규칙 유형#

히스토리

• 새로운 branch_type 필드:
• GitLab 16.1에서 security_policies_branch_type이라는 플래그와 함께 도입됨.
• GitLab 16.2에서 일반 가용성. 기능 플래그 제거됨.
• 새로운 branch_exceptions 필드:
• GitLab 16.3에서 security_policies_branch_exceptions라는 플래그와 함께 도입됨.
• GitLab 16.5에서 일반 가용성. 기능 플래그 제거됨.
• 예약된 스캔을 위한 파이프라인을 생성하는 새로운 scan_execution_pipeline_worker 워커:
• GitLab 16.11에서 플래그와 함께 도입됨.
• GitLab 17.5에서 GitLab.com에서 활성화됨.
• GitLab 17.6에서 일반 가용성. 기능 플래그 scan_execution_pipeline_worker 제거됨.
• 새로운 애플리케이션 설정 security_policy_scheduled_scans_max_concurrency:
• GitLab 17.1에서 도입됨. 동시성 제한은 scan_execution_pipeline_worker 및 scan_execution_pipeline_concurrency_control 모두 활성화된 경우 적용됩니다.
• GitLab 17.11에서 새로운 애플리케이션 설정 security_policy_scheduled_scans_max_concurrency가 제거됨.
• 스캔 실행 예약된 작업에 대한 동시성 제한:
• GitLab 17.3에서 scan_execution_pipeline_concurrency_control이라는 플래그와 함께 도입됨.
• GitLab 17.9에서 일반 가용성. 기능 플래그 scan_execution_pipeline_concurrency_control 제거됨.

schedule 규칙 유형을 사용하여 일정에 따라 보안 스캐너를 실행합니다.

예약된 파이프라인:

• 프로젝트의 .gitlab-ci.yml 파일에 정의된 작업이 아닌 정책에 정의된 스캐너만 실행합니다.
• cadence 필드에 정의된 일정에 따라 실행됩니다.
• 프로젝트의 security_policy_bot 사용자 계정으로 실행되며 Guest 역할과 파이프라인을 생성하고 CI/CD 작업에서 저장소 내용을 읽을 수 있는 권한을 갖습니다. 이 계정은 정책이 그룹 또는 프로젝트에 연결될 때 생성됩니다.
• GitLab.com에서는 스캔 실행 정책의 처음 10개 schedule 규칙만 강제됩니다. 제한을 초과하는 규칙은 효과가 없습니다.

1. branches, branch_type, agents 중 하나만 지정해야 합니다.

Cadence#

cadence 필드를 사용하여 정책의 작업을 실행할 시기를 예약합니다. cadence 필드는 cron 구문을 사용하지만 일부 제한이 있습니다:

• 다음 유형의 cron 구문만 지원됩니다:
  • 지정된 시간 전후의 하루에 한 번인 일별 cadence, 예: 0 18 * * *
  • 지정된 요일 및 지정된 시간 전후의 주에 한 번인 주별 cadence, 예: 0 13 * * 0
• 분 및 시간에 쉼표(,), 하이픈(-), 단계 연산자(/)는 지원되지 않습니다. 이러한 문자를 사용하는 모든 예약된 파이프라인은 건너뜁니다.

cadence 필드의 값을 선택할 때 다음을 고려하세요:

• 타이밍은 GitLab.com과 GitLab Dedicated의 경우 UTC를 기준으로 하고, GitLab Self-Managed의 경우 GitLab 호스트의 시스템 시간을 기준으로 합니다. 새 정책을 테스트할 때 파이프라인이 로컬 시간대가 아닌 서버의 시간대에 예약되기 때문에 잘못된 시간에 실행되는 것처럼 보일 수 있습니다.
• 예약된 파이프라인은 생성에 필요한 리소스를 사용할 수 있을 때까지 시작되지 않습니다. 즉, 파이프라인이 정책에 지정된 타이밍에 정확히 시작되지 않을 수 있습니다.

agents 필드와 함께 schedule 규칙 유형을 사용하는 경우:

• Kubernetes용 GitLab 에이전트는 30초마다 적용 가능한 정책이 있는지 확인합니다. 에이전트가 정책을 찾으면 스캔이 정의된 cadence에 따라 실행됩니다.
• Cron 표현식은 Kubernetes 에이전트 파드의 시스템 시간을 사용하여 평가됩니다.

branches 필드와 함께 schedule 규칙 유형을 사용하는 경우:

• Cron 워커는 15분 간격으로 실행되며 이전 15분 동안 실행되도록 예약된 파이프라인을 시작합니다. 따라서 예약된 파이프라인은 최대 15분의 오프셋으로 실행될 수 있습니다.
• 정책이 많은 수의 프로젝트 또는 브랜치에 강제되는 경우 정책이 배치로 처리되며 모든 파이프라인을 생성하는 데 시간이 걸릴 수 있습니다.

agent 스키마#

schedule 규칙 유형에서 agents 객체를 정의하기 위해 이 스키마를 사용합니다.

agent 예제#

- name: Enforce container scanning in cluster connected through my-gitlab-agent for default and kube-system namespaces
  enabled: true
  rules:
  - type: schedule
    cadence: '0 10 * * *'
    agents:
      <agent-name>:
        namespaces:
        - 'default'
        - 'kube-system'
  actions:
  - scan: container_scanning

일정 규칙의 키는 다음과 같습니다:

• cadence (필수): 스캔이 실행되는 시기에 대한 Cron 표현식.
• agents:<agent-name> (필수): 스캔에 사용할 에이전트 이름.
• agents:<agent-name>:namespaces (선택사항): 스캔할 Kubernetes 네임스페이스. 생략하면 모든 네임스페이스가 스캔됩니다.

time_window 스키마#

schedule 규칙 유형의 time_window 객체를 사용하여 시간에 따른 예약된 스캔 분산 방법을 정의합니다. 정책 편집기의 YAML 모드에서만 time_window를 구성할 수 있습니다.

time_window 예제#

- name: Enforce container scanning with a time window of 1 hour
  enabled: true
  rules:
  - type: schedule
    cadence: '0 10 * * *'
    time_window:
      value: 3600
      distribution: random
  actions:
  - scan: container_scanning

대규모 프로젝트에서 예약된 파이프라인 최적화#

정책이 여러 프로젝트와 브랜치에 걸쳐 예약된 파이프라인을 강제하는 경우 파이프라인이 동시에 실행됩니다. 각 프로젝트에서 예약된 파이프라인의 첫 번째 실행은 해당 프로젝트의 일정 실행을 담당하는 보안 봇 사용자를 생성합니다.

대규모 프로젝트의 성능을 최적화하려면:

• 프로젝트의 일부부터 시작하여 점차적으로 더 많은 프로젝트를 추가하는 점진적 도입을 사용합니다. 보안 정책 범위를 활용하여 특정 그룹, 프로젝트 또는 주어진 컴플라이언스 프레임워크 레이블이 포함된 프로젝트를 대상으로 합니다.
• 지정된 tag가 있는 실행기에서 일정을 실행하도록 정책을 구성할 수 있습니다. 정책에서 강제된 일정을 처리하고 다른 실행기에 대한 영향을 줄이기 위해 각 프로젝트에 전용 실행기를 설정하는 것을 고려하세요.
• 프로덕션에 배포하기 전에 스테이징 또는 하위 환경에서 구현을 테스트합니다. 성능을 모니터링하고 결과에 따라 도입 계획을 조정합니다.

예약된 스캔 실행 정책의 최대 예약 기간 구성#

예약된 스캔 실행 정책은 cron 표현식이 있는 cadence 필드를 사용하여 월별 예약을 지원합니다. 해당 기간 내에 스캔을 무작위로 분산시키기 위해 최대 2629746초(약 30일)까지 time_window를 구성할 수 있습니다.

예를 들어 30일 분산 창으로 월별 스캔을 예약하려면:

rules:
  - type: schedule
    cadence: '0 0 1 * *'  # Run on the first day of each month
    time_window:
      value: 2592000  # 30 days in seconds
      distribution: random

인스턴스 다운타임 중 예약된 스캔 이해#

예약된 스캔은 다음 실행 시간을 추적합니다. 성공적인 스캔 후 시스템은 다음 스캔이 실행되어야 하는 시기를 업데이트합니다. GitLab 인스턴스가 예약된 스캔 시간(유지 관리, 중단 또는 재시작으로 인해) 중 사용할 수 없는 경우 시스템은 이미 실행되었어야 하지만 실행되지 않은 스캔을 식별하고 인스턴스가 사용 가능해질 때 파이프라인을 생성합니다.

예약된 스캔이 있는 프로젝트 삭제#

프로젝트를 삭제하면 관련된 모든 예약된 스캔도 삭제됩니다. 삭제된 프로젝트에 대해서는 파이프라인이 실행되지 않습니다.

실행 중인 예약된 스캔 취소#

예약된 스캔을 취소하려면 두 가지 옵션이 있습니다:

• 개별 파이프라인 취소: 프로젝트에서 작업을 취소할 수 있는 필요한 권한이 있는 경우 파이프라인 보기에서 실행 중인 파이프라인을 직접 취소할 수 있습니다.
• 정책 비활성화: 정책 편집기에서 enabled: false를 설정하여 스캔 실행 정책을 비활성화합니다. 이미 실행 중이거나 다음 15분 내(약)에 실행될 예정인 스캔은 여전히 실행될 수 있습니다.

대규모 배포를 위한 권장 사항#

여러 프로젝트에 걸쳐 예약된 스캔 실행 정책을 배포할 때 다음 권장 사항을 고려하세요:

• 점진적 도입 사용: 소규모 프로젝트 집합으로 시작하여 점차적으로 더 많은 프로젝트를 추가합니다. 컴플라이언스 프레임워크 레이블을 사용하여 특정 프로젝트 그룹으로 정책의 범위를 지정합니다.
• time_window 구성: 예약된 정책에 항상 time_window 매개변수를 설정합니다. 설정하지 않으면 모든 파이프라인이 동일한 시간에 예약되어 성능 문제와 리소스 경합이 발생할 수 있습니다.
• 스테이징에서 테스트: 프로덕션에 배포하기 전에 스테이징 환경 또는 하위 환경에서 정책 구성을 검증합니다. 성능을 모니터링하고 결과에 따라 조정합니다.
• 실행기 용량 고려: 실행기에 미치는 영향은 정책 구성, 실행기 가용성, GitLab 인스턴스 배포에 따라 다릅니다. 부하를 분산하기 위해 특정 태그가 있는 실행기를 사용하도록 정책을 구성합니다.

예약된 스캔 최적화에 대한 자세한 내용은 대규모 프로젝트에서 예약된 파이프라인 최적화를 참조하세요.

동시성 제어#

time_window 속성을 설정하면 GitLab이 동시성 제어를 적용합니다.

동시성 제어는 정책에 정의된 time_window 설정에 따라 예약된 파이프라인을 분산합니다.

scan 작업 유형#

히스토리

• 스캔 실행 정책 변수 우선순위:
• GitLab 16.7에서 security_policies_variables_precedence라는 플래그와 함께 변경됨. 기본적으로 활성화됨.
• GitLab 16.8에서 일반 가용성. 기능 플래그 security_policies_variables_precedence 제거됨.
• 주어진 작업에 대한 보안 템플릿 선택:
• GitLab 17.1에서 scan_execution_policies_with_latest_templates라는 기능 플래그와 함께 프로젝트에 대해 도입됨. 기본적으로 비활성화됨.
• GitLab 17.2에서 scan_execution_policies_with_latest_templates_group이라는 기능 플래그와 함께 그룹에 대해 도입됨. 기본적으로 비활성화됨.
• GitLab 17.2에서 GitLab Self-Managed 및 GitLab Dedicated에서 활성화됨.
• GitLab 17.3에서 일반 가용성. 기능 플래그 scan_execution_policies_with_latest_templates 및 scan_execution_policies_with_latest_templates_group 제거됨.

이 작업은 정의된 정책에서 하나 이상의 규칙 조건이 충족될 때 추가 매개변수와 함께 선택한 scan을 실행합니다.

스캐너 동작#

일부 스캐너는 일반 CI/CD 파이프라인 스캔과 다르게 scan 작업에서 동작합니다:

• 정적 애플리케이션 보안 테스트(SAST): 저장소에 SAST에서 지원하는 파일이 포함된 경우에만 실행됩니다.
• 시크릿 탐지:
  • 기본 룰셋의 규칙만 기본적으로 지원됩니다.
  • 룰셋 구성을 사용자 정의하려면 다음 중 하나를 수행합니다:
    • 기본 룰셋을 수정합니다. 스캔 실행 정책을 사용하여 SECRET_DETECTION_RULESET_GIT_REFERENCE CI/CD 변수를 지정합니다. 기본적으로 기본 룰셋의 규칙만 재정의하거나 비활성화하는 원격 구성 파일을 가리킵니다. 이 변수만 사용하면 기본 규칙 집합을 확장하거나 교체하는 것을 지원하지 않습니다.
    • 기본 룰셋을 확장하거나 교체합니다. 스캔 실행 정책을 사용하여 SECRET_DETECTION_RULESET_GIT_REFERENCE CI/CD 변수와 Git passthrough를 사용하여 기본 룰셋을 확장하거나 교체하는 원격 구성 파일을 지정합니다. 자세한 가이드는 스캔 실행 정책을 통해 적용된 중앙 관리 파이프라인 시크릿 탐지 구성 설정 방법을 참조하세요.
  • scheduled 스캔 실행 정책의 경우 시크릿 탐지는 기본적으로 먼저 historic 모드(SECRET_DETECTION_HISTORIC_SCAN = true)로 실행됩니다. 이후의 모든 예약된 스캔은 마지막 실행과 현재 SHA 사이의 커밋 범위로 설정된 SECRET_DETECTION_LOG_OPTIONS가 있는 기본 모드로 실행됩니다. 스캔 실행 정책에서 CI/CD 변수를 지정하여 이 동작을 재정의할 수 있습니다. 자세한 내용은 전체 이력 파이프라인 시크릿 탐지를 참조하세요.
  • triggered 스캔 실행 정책의 경우 시크릿 탐지는 .gitlab-ci.yml에서 수동으로 구성된 일반 스캔처럼 작동합니다.
• 컨테이너 스캔: pipeline 규칙 유형에 대해 구성된 스캔은 agents 객체에 정의된 에이전트를 무시합니다. agents 객체는 schedule 규칙 유형에 대해서만 고려됩니다. agents 객체에 이름이 제공된 에이전트는 프로젝트에 대해 생성 및 구성되어야 합니다.

DAST 프로파일#

동적 애플리케이션 보안 테스트(DAST)를 강제할 때 다음 요구사항이 적용됩니다:

• 정책 범위의 모든 프로젝트에 대해 지정된 사이트 프로파일과 스캐너 프로파일이 있어야 합니다. 이것들이 없으면 정책이 적용되지 않고 오류 메시지가 있는 작업이 대신 생성됩니다.
• DAST 사이트 프로파일 또는 스캐너 프로파일이 활성화된 스캔 실행 정책에 명명된 경우 프로파일을 수정하거나 삭제할 수 없습니다. 프로파일을 편집하거나 삭제하려면 정책 편집기에서 정책을 비활성화로 설정하거나 YAML 모드에서 enabled: false를 설정해야 합니다.
• 예약된 DAST 스캔으로 정책을 구성할 때 보안 정책 프로젝트 저장소의 커밋 작성자는 스캐너 및 사이트 프로파일에 액세스할 수 있어야 합니다. 그렇지 않으면 스캔이 성공적으로 예약되지 않습니다.

스캔 설정#

scan_settings 매개변수에서 지원되는 설정:

CI/CD 변수#

스캔 실행 정책에 정의된 변수는 표준 CI/CD 변수 우선순위를 따릅니다.

스캔 실행 정책이 강제되는 모든 프로젝트에서 다음 CI/CD 변수에 미리 구성된 값이 사용됩니다. 정책만 이 값을 재정의할 수 있습니다. 그룹 또는 프로젝트 CI/CD 변수는 이러한 변수를 재정의할 수 없습니다:

DS_EXCLUDED_PATHS: spec, test, tests, tmp
SAST_EXCLUDED_PATHS: spec, test, tests, tmp
SECRET_DETECTION_EXCLUDED_PATHS: ''
SECRET_DETECTION_HISTORIC_SCAN: false
SAST_EXCLUDED_ANALYZERS: ''
DEFAULT_SAST_EXCLUDED_PATHS: spec, test, tests, tmp
DS_EXCLUDED_ANALYZERS: ''
SECURE_ENABLE_LOCAL_CONFIGURATION: true

GitLab 16.9 이하에서:

• _EXCLUDED_PATHS 접미사가 있는 CI/CD 변수가 정책에 선언된 경우 해당 값은 그룹 또는 프로젝트의 CI/CD 변수로 재정의될 수 있었습니다.
• _EXCLUDED_ANALYZERS 접미사가 있는 CI/CD 변수가 정책에 선언된 경우 해당 값은 정책, 그룹 또는 프로젝트 어디에서 정의되었든 무시되었습니다.

정책 범위 스키마#

정책 강제를 사용자 정의하려면 지정한 프로젝트, 그룹 또는 컴플라이언스 프레임워크 레이블을 포함하거나 제외하도록 정책의 범위를 정의할 수 있습니다. 자세한 내용은 범위를 참조하세요.

정책 업데이트 전파#

정책을 업데이트하면 업데이트 방법에 따라 변경 사항이 다르게 전파됩니다:

• 보안 정책 프로젝트의 머지 리퀘스트를 통해: 머지 리퀘스트가 병합된 직후 변경 사항이 적용됩니다.
• .gitlab/security-policies/policy.yml에 직접 커밋: 변경 사항이 적용되는 데 최대 10분이 걸릴 수 있습니다.

트리거 동작#

파이프라인 기반 정책(type: pipeline)에 대한 업데이트는 즉각적인 파이프라인을 트리거하지 않거나 이미 진행 중인 파이프라인에 영향을 미치지 않습니다. 정책 변경 사항은 향후 파이프라인 실행에 적용됩니다.

예약된 정책에서 규칙을 예약된 cadence 외부에서 수동으로 트리거할 수 없습니다.

예제 보안 정책 프로젝트#

보안 정책 프로젝트에 저장된 .gitlab/security-policies/policy.yml 파일에서 이 예제를 사용할 수 있습니다:

---
scan_execution_policy:
- name: Enforce DAST in every release pipeline
  description: This policy enforces pipeline configuration to have a job with DAST scan for release branches
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: dast
    scanner_profile: Scanner Profile A
    site_profile: Site Profile B
- name: Enforce DAST and secret detection scans every 10 minutes
  description: This policy enforces DAST and secret detection scans to run every 10 minutes
  enabled: true
  rules:
  - type: schedule
    branches:
    - main
    cadence: "*/10 * * * *"
  actions:
  - scan: dast
    scanner_profile: Scanner Profile C
    site_profile: Site Profile D
  - scan: secret_detection
    scan_settings:
      ignore_default_before_after_script: true
- name: Enforce secret detection and container scanning in every default branch pipeline
  description: This policy enforces pipeline configuration to have a job with secret detection and container scanning scans for the default branch
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
    variables:
      SAST_EXCLUDED_ANALYZERS: brakeman
  - scan: container_scanning

이 예제에서:

• release/* 와일드카드와 일치하는 브랜치(예: 브랜치 release/v1.2.1)에서 실행되는 모든 파이프라인에 대해
  • DAST 스캔이 Scanner Profile A 및 Site Profile B로 실행됩니다.
• DAST 및 시크릿 탐지 스캔이 10분마다 실행됩니다. DAST 스캔은 Scanner Profile C와 Site Profile D로 실행됩니다.
• main 브랜치에서 실행되는 모든 파이프라인에 대해 시크릿 탐지, 컨테이너 스캔, SAST 스캔이 실행됩니다. SAST 스캔은 SAST_EXCLUDED_ANALYZER 변수가 "brakeman"으로 설정되어 실행됩니다.

스캔 실행 정책 편집기 예제#

스캔 실행 정책 편집기의 YAML 모드에서 이 예제를 사용할 수 있습니다. 이전 예제의 단일 객체에 해당합니다.

name: Enforce secret detection and container scanning in every default branch pipeline
description: This policy enforces pipeline configuration to have a job with secret detection and container scanning scans for the default branch
enabled: true
rules:
  - type: pipeline
    branches:
      - main
actions:
  - scan: secret_detection
  - scan: container_scanning

중복 스캔 방지#

스캔 실행 정책은 프로젝트의 .gitlab-ci.yml 파일에 스캔 작업을 포함하는 경우 동일한 유형의 스캐너를 두 번 이상 실행할 수 있습니다.

스캐너가 다른 변수와 설정으로 두 번 이상 실행될 수 있기 때문에 중복 스캔은 의도적으로 실행됩니다. 예를 들어 정책을 통해 강제된 변수와 다른 변수로 SAST 스캔을 실행할 수 있습니다. 이 시나리오에서는 파이프라인에서 두 개의 SAST 작업이 실행됩니다:

• 사용자 정의 변수가 있는 작업.
• 정책 강제 변수가 있는 작업.

중복 스캔을 방지하려면 프로젝트의 .gitlab-ci.yml 파일에서 스캔 중 하나를 제거하거나 변수를 사용하여 로컬 작업을 건너뛸 수 있습니다. 작업을 건너뛰어도 스캔 실행 정책에 정의된 보안 작업이 실행되는 것을 방지하지 않습니다.

변수로 스캔 작업을 건너뛰려면 다음을 사용할 수 있습니다:

• SAST_DISABLED: "true" - SAST 작업 건너뛰기.
• DAST_DISABLED: "true" - DAST 작업 건너뛰기.
• CONTAINER_SCANNING_DISABLED: "true" - 컨테이너 스캔 작업 건너뛰기.
• SECRET_DETECTION_DISABLED: "true" - 시크릿 탐지 작업 건너뛰기.
• DEPENDENCY_SCANNING_DISABLED: "true" - 의존성 스캔 작업 건너뛰기.

작업을 건너뛸 수 있는 모든 변수의 개요는 CI/CD 변수 문서를 참조하세요.

트러블슈팅#

스캔 실행 정책 작업 시 다음과 같은 문제가 발생할 수 있습니다.

스캔 실행 정책 파이프라인이 생성되지 않음#

스캔 실행 정책이 type: pipeline에 정의된 파이프라인을 예상대로 생성하지 않는 경우 프로젝트의 .gitlab-ci.yml 파일에 정책이 파이프라인을 생성하지 못하게 하는 workflow:rules가 있을 수 있습니다.

type: pipeline 규칙이 있는 스캔 실행 정책은 병합된 CI/CD 구성을 기반으로 파이프라인을 생성합니다. 프로젝트의 workflow:rules가 파이프라인을 완전히 필터링하면 스캔 실행 정책이 파이프라인을 생성할 수 없습니다.

예를 들어 다음 workflow:rules 구성은 모든 파이프라인이 생성되지 않도록 합니다:

# .gitlab-ci.yml
workflow:
  rules:
  - if: $CI_PIPELINE_SOURCE == "push"
    when: never

해결 방법:

이 문제를 해결하려면 다음 옵션 중 하나를 사용할 수 있습니다:

• 스캔 실행 정책이 파이프라인을 생성할 수 있도록 프로젝트의 .gitlab-ci.yml 파일에서 workflow:rules를 수정합니다. $CI_PIPELINE_SOURCE 변수를 사용하여 정책에 의해 트리거된 파이프라인을 식별할 수 있습니다:

  workflow:
    rules:
    - if: $CI_PIPELINE_SOURCE == "security_orchestration_policy"
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never
  

• type: pipeline 규칙 대신 type: schedule 규칙을 사용합니다. 예약된 스캔 실행 정책은 workflow:rules에 영향을 받지 않으며 정의된 일정에 따라 파이프라인을 생성합니다.

• CI/CD 파이프라인에서 보안 스캔이 실행되는 시기와 방법에 대한 더 많은 제어를 위해 파이프라인 실행 정책을 사용합니다.