제한 사항
작업
스캔 실행 정책 편집기
스캔 실행 정책 스키마
스캔 실행 정책 스키마
pipeline 규칙 유형
schedule 규칙 유형
- 주기
- agent 스키마
  - 정책 예시
scan 작업 유형
CI/CD 변수
범위 보안 정책
- 정책 범위 스키마
  - policy_scope 범위 유형
  - 보안 정책 범위가 포함된 예제 policy.yml
보안 정책 프로젝트 예시
스캔 실행 정책 편집기 예시
중복 스캔 방지
실험적 기능

스캔 실행 정책

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

그룹 수준의 보안 정책이 도입됨 GitLab 15.2에서.

그룹 수준의 보안 정책이 활성화됨 GitLab.com에서 GitLab 15.4에서.

운영 컨테이너 스캐닝이 도입됨 GitLab 15.5에서.

스캔 실행 정책 편집기에서 사용자 정의 CI 변수를 지원하는 기능이 도입됨 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에서 제거됨.

스캔 실행 정책을 사용하여 보안 스캔을 시행하십시오. 파이프라인의 일부로 또는
지정된 일정에 따라 보안 스캔이 실행됩니다. 정책을 그룹 또는 하위 그룹 수준에서 정의하면
여러 프로젝트 파이프라인에서 보안 스캔이 실행됩니다.

스캔 실행 정책은 모든 적합한 프로젝트에 대해 시행됩니다.
.gitlab-ci.yml 파일이 없는 프로젝트나 AutoDevOps가 비활성화된 경우 보안 정책은
.gitlab-ci.yml 파일을 암시적으로 만들어냅니다. 이는 비밀 탐지, 정적 분석 또는
프로젝트에서 빌드를 요구하지 않는 다른 스캐너의 실행을 가능하게 하는 정책이 여전히
실행되고 시행될 수 있도록 합니다.

이 기능은 규정 준수 파이프라인와 일부 중복됩니다.
우리는 이 두 기능에 대한 사용자 경험을 통합하지 않았습니다.
이 기능들 간의 유사점과 차이점에 대한 자세한 내용은
스캔 실행 시행을 참조하세요.

비디오 워크스루는 GitLab에서 보안 스キャン 정책 설정 방법을 참조하십시오.
개요는 GitLab CI/CD 구성이 없는 프로젝트에서 스캔 실행 정책 시행을 참조하십시오.

제한 사항

각 정책에 최대 다섯 개의 규칙을 할당할 수 있습니다.
각 보안 정책 프로젝트에 최대 다섯 개의 스캔 실행 정책을 할당할 수 있습니다.

작업

DAST 스캔 이외의 스캔을 위한 정책 작업은 파이프라인의 test 단계에서 생성됩니다.
기본 파이프라인에서 test 단계를 제거하면 작업은 대신 scan-policies 단계에서 실행됩니다.
이 단계는 평가 시 CI/CD 파이프라인에 주입됩니다.
build 단계가 존재하는 경우, build 단계 뒤에 주입되며, 존재하지 않으면 파이프라인의 시작 부분에 주입됩니다.
DAST 스캔은 항상 dast 단계에서 실행됩니다. 이 단계가 존재하지 않으면 파이프라인의 끝에 dast 단계가 주입됩니다.

작업 이름 충돌을 피하기 위해, 작업 이름 뒤에 하이픈과 숫자가 추가됩니다.
숫자는 정책 작업에 대해 고유합니다.

스캔 실행 정책 편집기

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

사전 요구 사항:

그룹, 하위 그룹 또는 프로젝트 소유자만 권한을 가지고 보안 정책 프로젝트를 선택할 수 있습니다.

정책이 완료되면 편집기 하단에서 Merge Request로 구성을 선택하여 저장합니다. 이후 프로젝트에 설정된 보안 정책 프로젝트의 머지 요청으로 리디렉션됩니다. 프로젝트에 연결된 보안 정책 프로젝트가 없으면 자동으로 생성됩니다. 기존 정책은 편집기 인터페이스의 하단에서 정책 삭제를 선택하여 제거할 수 있습니다.

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

참고: DAST 실행 정책에 대한 규칙 모드 편집기를 사용하여 사이트 및 스캐너 프로필을 선택할 때, 정책이 프로젝트 수준에서 생성되고 있는지 그룹 수준에서 생성되고 있는지에 따라 다릅니다. 프로젝트 수준 정책의 경우 규칙 모드 편집기는 프로젝트에서 이미 정의된 프로필 목록을 제공합니다. 그룹 수준 정책의 경우 사용해야 할 프로필의 이름을 입력해야 하며, 파이프라인 오류를 방지하기 위해 일치하는 이름을 가진 프로필이 그룹의 모든 프로젝트에 존재해야 합니다.

스캔 실행 정책 스키마

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

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

필드	유형	필수	가능한 값	설명
`scan_execution_policy`	`array` 스캔 실행 정책	true		스캔 실행 정책 목록 (최대 5개)

스캔 실행 정책 스키마

도입됨 GitLab 17.4에서 scan_execution_policy_action_limit (프로젝트용) 및 scan_execution_policy_action_limit_group (그룹용) 플래그와 함께. 기본적으로 비활성화되어 있습니다.

이 기능의 사용 가능성은 기능 플래그에 의해 제어됩니다. 더 많은 정보는 이력을 참조하세요.

필드	유형	필수	가능한 값	설명
`name`	`string`	true		정책 이름. 최대 255자.
`description` (선택 사항)	`string`	true		정책 설명.
`enabled`	`boolean`	true	`true`, `false`	정책을 활성화(`true`) 또는 비활성화(`false`)하는 플래그.
`rules`	`array` 규칙	true		정책이 적용되는 규칙 목록.
`actions`	`array` 작업	true		정책이 시행하는 작업 목록. GitLab 18.0 이상에서 최대 10개로 제한.

`pipeline` 규칙 유형

branch_type 필드는 GitLab 16.1 에서 도입되었습니다 보안 정책 브랜치 유형이라는 플래그와 함께. GitLab 16.2에서 일반적으로 사용 가능합니다. 기능 플래그가 제거되었습니다.

branch_exceptions 필드는 GitLab 16.3 에서 도입되었습니다 보안 정책 브랜치 예외라는 플래그와 함께. GitLab 16.5에서 일반적으로 사용 가능합니다. 기능 플래그가 제거되었습니다.

이 규칙은 파이프라인이 선택된 브랜치에서 실행될 때 정의된 작업을 시행합니다.

필드	유형	필수	가능한 값	설명
`type`	`string`	true	`pipeline`	규칙의 유형입니다.
`branches` ¹	`array` of `string`	`branch_type` 필드가 존재하지 않는 경우 true	`*` 또는 브랜치 이름	주어진 정책이 적용되는 브랜치(와일드카드 지원).
`branch_type` ¹	`string`	`branches` 필드가 존재하지 않는 경우 true	`default`, `protected` 또는 `all`	주어진 정책이 적용되는 브랜치 유형.
`branch_exceptions`	`array` of `string`	false	브랜치 이름	이 규칙에서 제외할 브랜치.

branches 또는 branch_type 중 하나만 지정해야 합니다.

`schedule` 규칙 유형

branch_type 필드는 GitLab 16.1 에서 도입되었습니다 보안 정책 브랜치 유형이라는 플래그와 함께. GitLab 16.2에서 일반적으로 사용 가능합니다. 기능 플래그가 제거되었습니다.

branch_exceptions 필드는 GitLab 16.3 에서 도입되었습니다 보안 정책 브랜치 예외라는 플래그와 함께. GitLab 16.5에서 일반적으로 사용 가능합니다. 기능 플래그가 제거되었습니다.

경고:
GitLab 16.1 및 이전 버전에서는 예약된 스캔 실행 정책과 함께 직접 전송을 사용해서는 안 됩니다. 직접 전송을 사용하는 경우, 먼저 GitLab 16.2로 업그레이드하고, enforcing하고 있는 프로젝트에서 보안 정책 봇이 활성화되어 있는지 확인하세요.

schedule 규칙 유형을 사용하여 예약된 시간에 보안 스캐너를 실행하세요.

예약된 파이프라인:

정책에 정의된 스캐너만 실행하며, 프로젝트의 .gitlab-ci.yml 파일에서 정의된 작업은 실행하지 않습니다.
cadence 필드에 정의된 일정에 따라 실행됩니다.
security_policy_bot 사용자 계정으로 프로젝트에서 실행되며, 게스트 역할을 가지고 CI/CD 작업에서 파이프라인을 생성하고 리포지토리의 내용을 읽을 수 있는 권한이 있습니다. 이 계정은 정책이 그룹 또는 프로젝트에 연결될 때 생성됩니다.

필드	유형	필수	가능한 값	설명
`type`	`string`	true	`schedule`	규칙의 유형입니다.
`branches` ¹	`array` of `string`	`branch_type` 또는 `agents` 필드가 존재하지 않는 경우 true	`*` 또는 브랜치 이름	주어진 정책이 적용되는 브랜치(와일드카드 지원).
`branch_type` ¹	`string`	`branches` 또는 `agents` 필드가 존재하지 않는 경우 true	`default`, `protected` 또는 `all`	주어진 정책이 적용되는 브랜치 유형.
`branch_exceptions`	`array` of `string`	false	브랜치 이름	이 규칙에서 제외할 브랜치.
`cadence`	`string`	true	Cron 표현식 (예: `0 0 * * *`)	예약된 시간을 나타내는 다섯 개의 필드를 포함하는 공백으로 구분된 문자열입니다.
`timezone`	`string`	false	시간대 식별자 (예: `America/New_York`)	캘린더에 적용할 시간대. 값은 IANA 시간대 데이터베이스 식별자여야 합니다.
`agents` ¹	`object`	`branch_type` 또는 `branches` 필드가 존재하지 않는 경우 true		Operational Container Scanning이 실행되는 GitLab 에이전트의 이름입니다. 객체 키는 GitLab에서 프로젝트에 대해 구성된 Kubernetes 에이전트의 이름입니다.

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

주기

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

지원되는 cron 구문의 유형은 다음과 같습니다:
- 지정된 시간 주위에서 시간당 한 번의 일일 주기, 예: 0 18 * * *
- 지정된 요일과 시간 주위에서 주마다 한 번의 주간 주기, 예: 0 13 * * 0
분과 시간에 대해 쉼표(,), 하이픈(-) 또는 단계 연산자(/)의 사용은 지원되지 않습니다.

이러한 문자를 사용하는 예약된 파이프라인은 건너뜁니다.

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

타이밍은 GitLab SaaS에 대해 UTC를 기준으로 하며, GitLab 자체 관리의 경우 GitLab 호스트의 시스템 시간을 기준으로 합니다. 새로운 정책을 테스트할 때는 파이프라인이 제대로 실행되지 않는 것처럼 보일 수 있지만, 실제로는 서버의 시간대에 따라 예약되어 있을 수 있습니다.
예약된 파이프라인은 정책에서 언급된 시간 주위에 시작되며, 리소스가 생성 가능해져야 실행됩니다. 즉, 파이프라인은 정책에 지정된 정확한 시간에 시작되지 않을 수 있습니다.

agents 필드와 함께 schedule 규칙 유형을 사용할 때:

Kubernetes를 위한 GitLab 에이전트는 적용 가능한 정책이 있는지 매 30초마다 확인합니다. 정책이 발견되면, 정의된 cadence에 따라 스캔이 실행됩니다.
cron 표현식은 Kubernetes-agent 포드의 시스템 시간을 사용하여 평가됩니다.

branches 필드와 함께 schedule 규칙 유형을 사용할 때:

cron 작업자는 15분 간격으로 실행되며, 이전 15분 동안 실행되도록 예약된 모든 파이프라인을 시작합니다. 따라서 예약된 파이프라인은 최대 15분의 오프셋으로 실행될 수 있습니다.
많은 프로젝트나 브랜치에 정책이 적용되면, 정책은 배치로 처리되며 모든 파이프라인을 생성하는 데 다소 시간이 걸릴 수 있습니다.

`agent` 스키마

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

필드	타입	필수	설명
`namespaces`	`문자열`의 `배열`	true	스캔할 네임스페이스입니다. 비어 있으면 모든 네임스페이스가 스캔됩니다.

정책 예시

- name: my-gitlab-agent를 통해 연결된 클러스터에서 default와 kube-system 네임스페이스에 대한 컨테이너 스캔 시행
  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 네임스페이스입니다. 생략 시 모든 네임스페이스가 스캔됩니다.

`scan` 작업 유형

스캔 실행 정책 변수 우선순위는 GitLab 16.7에서 변경되었습니다 플래그 이름 security_policies_variables_precedence를 사용하여. 기본적으로 활성화되어 있습니다. 기능 플래그는 GitLab 16.8에서 제거되었습니다.

주어진 작업에 대한 보안 템플릿 선택(프로젝트용)은 GitLab 17.1에서 도입되었습니다 기능 플래그 이름 scan_execution_policies_with_latest_templates로. 기본적으로 비활성화되어 있습니다.

주어진 작업에 대한 보안 템플릿 선택(그룹용)은 GitLab 17.2에서 도입되었습니다 기능 플래그 이름 scan_execution_policies_with_latest_templates_group로. 기본적으로 비활성화되어 있습니다.

주어진 작업에 대한 보안 템플릿 선택(프로젝트 및 그룹용)은 GitLab 17.2에서 셀프 매니지드 및 GitLab 전용에서 활성화되었습니다 (1, 2).

주어진 작업에 대한 보안 템플릿 선택(프로젝트 및 그룹용)은 GitLab 17.3에서 일반적으로 제공됩니다. 기능 플래그 scan_execution_policies_with_latest_templates 및 scan_execution_policies_with_latest_templates_group가 제거되었습니다.

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

필드	유형	가능한 값	설명
`scan`	`string`	`sast`, `sast_iac`, `dast`, `secret_detection`, `container_scanning`, `dependency_scanning`	작업의 유형입니다.
`site_profile`	`string`	선택한 DAST 사이트 프로필의 이름입니다.	DAST 스캔을 실행할 DAST 사이트 프로필입니다. 이 필드는 `scan` 유형이 `dast`인 경우에만 설정해야 합니다.
`scanner_profile`	`string` 또는 `null`	선택한 DAST 스캐너 프로필의 이름입니다.	DAST 스캔을 실행할 DAST 스캐너 프로필입니다. 이 필드는 `scan` 유형이 `dast`인 경우에만 설정해야 합니다.
`variables`	`object`		선택된 스캔에 적용하고 시행할 CI 변수 집합으로, `key: value` 쌍의 배열로 제공됩니다. `key`는 변수 이름이며, 그 `value`는 문자열로 제공됩니다. 이 매개변수는 지정된 스캔에 대해 GitLab CI 작업이 지원하는 모든 변수를 지원합니다.
`tags`	`array` of `string`		정책의 러너 태그 목록입니다. 정책 작업은 지정된 태그가 있는 러너에 의해 실행됩니다.
`template`	`string`	`default`, `latest`	시행할 CI/CD 템플릿 버전입니다. `latest` 버전은 중대한 변경 사항을 도입할 수 있습니다.
`scan_settings`	`object`		선택된 스캔에 적용하고 시행할 스캔 설정 집합으로, `key: value` 쌍의 배열로 제공됩니다. `key`는 설정 이름이며, 그 `value`는 불리언 또는 문자열로 제공됩니다. 이 매개변수는 스캔 설정에서 정의된 설정을 지원합니다.

참고:

Merge Request 파이프라인이 프로젝트에 대해 활성화된 경우, 각 시행된 스캔에 대해 정책에서 template: latest를 선택해야 합니다. 최신 템플릿을 사용하는 것은 Merge Request 파이프라인과의 호환성에 중요하며 GitLab 보안 기능을 최대한 활용할 수 있습니다. Merge Request 파이프라인에서 보안 스캔 도구를 사용하는 방법에 대한 자세한 내용은 보안 스캔 문서를 참조하세요.

스캐너 동작

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

정적 애플리케이션 보안 테스트(SAST): 리포지토리에 SAST에서 지원하는 파일이 있을 경우에만 실행됩니다.
비밀 탐지:
- 기본 규칙 집합이 있는 규칙만 지원됩니다. 사용자 정의 규칙 집합은 지원되지 않습니다. 대신, 원격 구성 파일을 구성하고 SECRET_DETECTION_RULESET_GIT_REFERENCE 변수를 설정할 수 있습니다.
- scheduled 스캔 실행 정책의 경우, 비밀 탐지는 기본적으로 historic 모드에서 먼저 실행됩니다 (SECRET_DETECTION_HISTORIC_SCAN = true). 이후 모든 예약된 스캔은 기본 모드에서 실행되며, SECRET_DETECTION_LOG_OPTIONS는 마지막 실행과 현재 SHA 사이의 커밋 범위로 설정됩니다. 이 동작은 스캔 실행 정책에서 CI/CD 변수를 지정하여 재정의할 수 있습니다. 자세한 내용은 전체 이력 파이프라인 비밀 탐지를 참조하세요.
- triggered 스캔 실행 정책의 경우, 비밀 탐지는 .gitlab-ci.yml에서 수동으로 구성된 것과 같이 작동합니다.
컨테이너 스캐닝: pipeline 규칙 유형에 대해 구성된 스캔은 agents 객체에서 정의된 에이전스를 무시합니다. agents 객체는 단지 schedule 규칙 유형에 대해서만 고려됩니다. agents 객체에 제공된 이름의 에이전트가 프로젝트를 위해 생성되고 구성되어야 합니다.

DAST 프로파일

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

정책 범위 내의 모든 프로젝트에 대해 지정된 사이트 프로파일과 스캐너 프로파일이 존재해야 합니다. 이러한 프로파일이 없으면, 정책이 적용되지 않으며 오류 메시지를 포함한 작업이 생성됩니다.
활성화된 스캔 실행 정책에 DAST 사이트 프로파일 또는 스캐너 프로파일이 명명된 경우, 프로파일을 수정하거나 삭제할 수 없습니다. 프로파일을 편집하거나 삭제하려면, 먼저 정책 편집기에서 비활성화로 설정하거나 YAML 모드에서 enabled: false로 설정해야 합니다.
예약된 DAST 스캔으로 정책을 구성할 때, 보안 정책 프로젝트 리포지토리에서 커밋의 작성자는 스캐너 및 사이트 프로파일에 접근할 수 있어야 합니다. 그렇지 않으면 스캔이 성공적으로 예약되지 않습니다.

스캔 설정

다음 설정은 scan_settings 매개변수에 의해 지원됩니다:

설정	유형	필수	가능한 값	기본값	설명
`ignore_default_before_after_script`	`boolean`	false	`true`, `false`	`false`	스캔 작업에서 파이프라인 구성의 기본 `before_script` 및 `after_script` 정의를 제외할지 여부를 지정합니다.

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: ''
DS_EXCLUDED_ANALYZERS: ''

GitLab 16.9 이전:

_EXCLUDED_PATHS로 끝나는 CI/CD 변수가 정책에서 선언된 경우, 이들의 값은 그룹 또는 프로젝트 CI/CD 변수에 의해 _재정의될 수 있었습니다.
_EXCLUDED_ANALYZERS로 끝나는 CI/CD 변수가 정책에서 선언된 경우, 이들의 값은 정책, 그룹 또는 프로젝트와 관계없이 무시되었습니다.

범위 보안 정책

GitLab 16.7에서 security_policies_policy_scope라는 플래그와 함께 도입됨. 기본적으로 활성화됨.

GitLab 16.11에서 일반적으로 사용 가능. 기능 플래그 security_policies_policy_scope가 제거됨.

그룹에 의한 스코프 도입됨 GitLab 17.4에서.

보안 정책 집행은 다음 간 링크를 설정하는 것에 따라 달라집니다:

정책을 집행하려는 그룹, 하위 그룹 또는 프로젝트
정책이 포함된 보안 정책 프로젝트.

예를 들어, 정책을 그룹에 연결하고자 할 경우, 그룹 소유자가 보안 정책 프로젝트에 대한 링크를 생성해야 합니다. 그런 다음 보안 정책 프로젝트의 모든 정책이 그룹의 모든 프로젝트에 상속됩니다.

보안 정책의 범위는 policy.yml 파일에서 범위를 설정하여 정의합니다:

적용된 컴플라이언스 프레임워크 ID를 사용하여 포함 된 프로젝트만 포함합니다. 프로젝트를 포함하려면, policy_scope.compliance_frameworks.id를 사용하여 적용된 컴플라이언스 프레임워크의 ID를 지정합니다.
집행에서 선택된 프로젝트를 _포함_하거나 _제외_합니다. 프로젝트의 ID를 사용하여 지정합니다.
선택된 그룹을 _포함_합니다. 선택적으로 projects 객체와 함께 사용하여 선택된 프로젝트를 제외할 수 있습니다.

정책 범위 스키마

정책 범위는 이 스키마를 준수해야 합니다.

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

`policy_scope` 범위 유형

정책 범위는 두 가지 유형 중 하나입니다.

필드	유형	가능한 값	설명
`compliance_frameworks`	`array`		집행 범위에 있는 컴플라이언스 프레임워크의 ID 목록, `id` 키를 가진 객체 배열로 구성됩니다.
`projects`	`object`	`including`, `excluding`	`excluding:` 또는 `including:`을 사용한 후 포함하거나 제외하려는 프로젝트의 ID를 `id` 키를 가진 객체 배열로 나열합니다.
`groups`	`object`	`including`	`including:`을 사용한 후 포함하려는 그룹의 ID를 `id` 키를 가진 객체 배열로 나열합니다.

보안 정책 범위가 포함된 예제 `policy.yml`

이 예제에서 보안 정책은 다음을 포함합니다:

ID가 2 또는 11인 컴플라이언스 프레임워크가 적용된 모든 프로젝트를 포함합니다.
ID가 24 또는 27인 프로젝트를 제외합니다.

---
scan_execution_policy:
- name: 모든 릴리스 파이프라인에 DAST 집행
  description: 이 정책은 릴리스 브랜치에 DAST 스캔 작업이 포함되도록 파이프라인 구성을 집행합니다.
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: dast
    scanner_profile: Scanner Profile A
    site_profile: Site Profile B
  policy_scope:
    compliance_frameworks:
      - id: 2
      - id: 11
- name: 모든 기본 브랜치 파이프라인에 비밀 탐지 및 컨테이너 스캔 집행
  description: 이 정책은 기본 브랜치에 대해 비밀 탐지 및 컨테이너 스캔 작업이 포함되도록 파이프라인 구성을 집행합니다.
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
    variables:
      SAST_EXCLUDED_ANALYZERS: brakeman
  policy_scope:
    projects:
      excluding:
        - id: 24
        - id: 27

보안 정책 프로젝트 예시

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

---
scan_execution_policy:
- name: 모든 릴리스 파이프라인에서 DAST 적용
  description: 이 정책은 릴리스 브랜치에 대해 DAST 스캔 작업을 포함하도록 파이프라인 구성을 시행합니다.
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: dast
    scanner_profile: Scanner Profile A
    site_profile: Site Profile B
- name: 10분마다 DAST 및 비밀 탐지 스캔 적용
  description: 이 정책은 10분마다 DAST 및 비밀 탐지 스캔을 실행하도록 시행합니다.
  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: 모든 기본 브랜치 파이프라인에서 비밀 탐지 및 컨테이너 스캔 적용
  description: 이 정책은 기본 브랜치에 대해 비밀 탐지 및 컨테이너 스캔 작업을 포함하도록 파이프라인 구성을 시행합니다.
  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와 함께 실행됩니다.
비밀 탐지, 컨테이너 스캔 및 SAST 스캔은 main 브랜치에서 실행되는 모든 파이프라인에 대해 실행됩니다. SAST 스캔은 변수 "brakeman"으로 설정된 SAST_EXCLUDED_ANALYZER와 함께 실행됩니다.

스캔 실행 정책 편집기 예시

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

name: 모든 기본 브랜치 파이프라인에서 비밀 탐지 및 컨테이너 스캔 적용
description: 이 정책은 기본 브랜치에 대해 비밀 탐지 및 컨테이너 스캔 작업을 포함하도록 파이프라인 구성을 시행합니다.
enabled: true
rules:
  - type: pipeline
    branches:
      - main
actions:
  - scan: secret_detection
  - scan: container_scanning

중복 스캔 방지

스캔 실행 정책에 따라 개발자가 프로젝트의 .gitlab-ci.yml 파일에 스캔 작업을 포함시키면 동일한 유형의 스캐너가 여러 번 실행될 수 있습니다. 이 동작은 의도적이며, 스캐너는 다양한 변수 및 설정으로 여러 번 실행될 수 있습니다. 예를 들어, 개발자는 보안 및 준수 팀에서 시행한 것과는 다른 변수를 사용하여 SAST 스캔을 실행해 보고 싶을 수 있습니다. 이 경우, 개발자의 변수로 실행된 SAST 작업과 보안 및 준수 팀의 변수로 실행된 SAST 작업이 각각 파이프라인에서 실행됩니다.

중복 스캔을 피하려면 프로젝트의 .gitlab-ci.yml 파일에서 스캔을 제거하거나, SAST_DISABLED: "true"로 로컬 작업을 비활성화할 수 있습니다. 이 방법으로 작업을 비활성화해도 스캔 실행 정책에 정의된 보안 작업이 실행되는 것을 막지 않습니다.

실험적 기능

Status: Experiment has ended

이 실험은 종료되었으며 계속되지 않을 것입니다. 이번 실험에서 받은 피드백을 바탕으로 우리는 사용자 정의 CI의 실행을 위한 새로운 정책 유형에 노력을 집중할 것입니다. 이 실험은 17.3에서 제거될 것입니다.

pipeline execution policy에 대해 더 알아보세요.

스캔 실행 정책

제한 사항

작업

스캔 실행 정책 편집기

스캔 실행 정책 스키마

스캔 실행 정책 스키마

`pipeline` 규칙 유형

`schedule` 규칙 유형

주기

`agent` 스키마

정책 예시

`scan` 작업 유형

스캐너 동작

DAST 프로파일

스캔 설정

CI/CD 변수

범위 보안 정책

정책 범위 스키마

`policy_scope` 범위 유형

보안 정책 범위가 포함된 예제 `policy.yml`

보안 정책 프로젝트 예시

스캔 실행 정책 편집기 예시

중복 스캔 방지

실험적 기능

도움말

기능 사용 가능성과 제품 평가판

도움받기

스캔 실행 정책

제한 사항

작업

스캔 실행 정책 편집기

스캔 실행 정책 스키마

스캔 실행 정책 스키마

pipeline 규칙 유형

schedule 규칙 유형

주기

agent 스키마

정책 예시

scan 작업 유형

스캐너 동작

DAST 프로파일

스캔 설정

CI/CD 변수

범위 보안 정책

정책 범위 스키마

policy_scope 범위 유형

보안 정책 범위가 포함된 예제 policy.yml

보안 정책 프로젝트 예시

스캔 실행 정책 편집기 예시

중복 스캔 방지

실험적 기능

도움말

기능 사용 가능성과 제품 평가판

도움받기

`pipeline` 규칙 유형

`schedule` 규칙 유형

`agent` 스키마

`scan` 작업 유형

`policy_scope` 범위 유형

보안 정책 범위가 포함된 예제 `policy.yml`