요구 사항 및 제한 사항
스캔 실행 정책 편집기
스캔 실행 정책 스키마
스캔 실행 정책 스키마
pipeline 규칙 유형
schedule 규칙 유형
- agent 스키마
  - 정책 예시
scan 액션 타입
보안 정책 프로젝트 예제
스캔 실행 정책 편집기 예제
중복 스캔 방지하기
실험적 기능
- 파이프라인 실행 정책 작업
- 보안 정책 범위
  - 정책 범위 스키마
  - policy_scope 범위 유형

스캔 실행 정책

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

- 그룹 수준 보안 정책은 GitLab 15.2에서 도입되었습니다. - 그룹 수준 보안 정책은 GitLab 15.4에서 GitLab.com에서 활성화되었습니다. - 운영 컨테이너 스캔은 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이라는 이름의 특징 플래그가 있습니다. 기본적으로 비활성화되어 있습니다.

자체 관리 GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 사용하려면 관리자가 특징 플래그인 allow_restricted_variables_at_policy_level을 활성화해야 합니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 그룹, 서브그룹 또는 프로젝트 소유자는 스캔 실행 정책을 사용하여 보안 스캔을 특정 일정에 맞추거나 프로젝트 파이프라인에서 실행할 수 있습니다. 정책을 그룹 또는 서브그룹 수준에서 정의하면 하나의 정책을 여러 프로젝트 파이프라인에서 실행할 수 있습니다. GitLab은 필요한 스캔을 새 작업으로 CI/CD 파이프라인에 삽입합니다.

스캔 실행 정책은 모든 해당 프로젝트에 대해 강제로 적용되며, GitLab CI/CD 구성 파일이 없거나 AutoDevOps가 비활성화된 프로젝트도 포함됩니다. 보안 정책은 파일을 암시적으로 생성하여 정책을 강제할 수 있도록 합니다. 이는 프로젝트에서 빌드가 필요하지 않은 시크릿 탐지, 정적 분석 또는 다른 스캐너 실행이 가능하고 강제되도록 하는 정책을 생성합니다.

GitLab은 작업 이름에 하이픈과 번호를 추가합니다. 번호는 이름 충돌을 피하기 위해 각 정책 조치마다 고유합니다. 그룹 수준 정책의 경우 모든 하위 프로젝트나 서브그룹에 적용됩니다. 하위 프로젝트나 서브그룹에서 그룹 수준 정책을 편집할 수는 없습니다.

이 기능은 컴플라이언스 프레임워크 파이프라인과 일부 중복이 있습니다. 두 기능에 대한 사용자 경험을 통합하지 않았기 때문입니다. 두 기능의 유사점과 차이점에 대한 자세한 내용은 스캔 실행 강제를 참조하세요.

DAST 스캔 이외의 스캔에 대한 정책 작업은 파이프라인의 test 단계에 생성됩니다. 기본 파이프라인의 stages를 수정하여 test 단계를 제거하면 작업은 대신 scan-policies 단계에서 실행됩니다. 이 단계는 존재하지 않을 경우 CI 파이프라인에 주입됩니다. build 단계가 존재하면 build 단계 바로 뒤에 삽입됩니다. build 단계가 없으면 파이프라인의 맨 앞에 삽입됩니다. DAST 스캔은 항상 dast 단계에서 실행됩니다. 이 단계가 존재하지 않는 경우 파이프라인의 끝에 dast 단계가 주입됩니다.

비디오 안내를 보려면 GitLab에서 보안 스캔 정책 설정하는 방법을(를) 참조하세요.
개요를 보려면 GitLab CI/CD 구성이 없는 프로젝트에서 스캔 실행 정책을 강제을(를) 참조하세요.

요구 사항 및 제한 사항

보안 정책 프로젝트 당 최대 스캔 실행 정책 수는 5개입니다.

스캔 실행 정책 편집기

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

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

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

DAST 실행 정책을 위한 사이트 및 스캐너 프로필 선택이 프로젝트 또는 그룹 수준에서 생성되는 경우 규칙 모드 편집기가 달라집니다. 프로젝트 수준 정책의 경우 규칙 모드 편집기는 이미 프로젝트에서 정의된 프로필 목록을 선택하도록 제시합니다. 그룹 수준 정책의 경우 사용할 프로필 이름을 입력해야 하며 파이프라인 오류를 방지하기 위해 해당 그룹의 모든 프로젝트에 해당하는 프로필이 있어야 합니다.

스캔 실행 정책 스키마

스캔 실행 정책을 포함한 YAML 파일은 scan_execution_policy 키 아래에 중첩된 스캔 실행 정책 스키마를 매치하는 객체 배열으로 구성됩니다. scan_execution_policy 키 아래에 최대 5개의 정책을 구성할 수 있습니다. 첫 5개보다 더 많은 정책을 구성하면 적용되지 않습니다.

새 정책을 저장할 때 GitLab은 해당 내용을 이 JSON 스키마에 대해 유효성을 검사합니다. JSON 스키마의 해석법을 모른다면 다음 섹션과 테이블이 대안을 제공합니다.

필드	타입	필수 여부	가능한 값	설명
`scan_execution_policy`	스캔 실행 정책의 `array`	true		스캔 실행 정책의 목록 (최대 5개)

스캔 실행 정책 스키마

필드	타입	필수 여부	가능한 값	설명
`name`	`string`	true		정책의 이름. 최대 255자.
`description` (선택 사항)	`string`	true		정책 설명.
`enabled`	`boolean`	true	`true`, `false`	정책을 활성화(`true`) 또는 비활성화(`false`)하는 플래그.
`rules`	규칙의 `array`	true		정책이 적용되는 규칙의 목록.
`actions`	작업의 `array`	true		정책이 시행하는 동작의 목록.

`pipeline` 규칙 유형

branch_type 필드가 도입되었습니다 GitLab 16.1에 이름이 security_policies_branch_type인 플래그와 함께. GitLab 16.2에서 일반적으로 사용 가능합니다. 플래그가 제거되었습니다.
branch_exceptions 필드가 도입되었습니다 GitLab 16.3에 이름이 security_policies_branch_exceptions인 플래그와 함께. GitLab 16.5에서 일반적으로 사용 가능합니다. 플래그가 제거되었습니다.

플랫폼 별: 자체 관리 GitLab에서는 기본적으로 branch_exceptions 필드를 사용할 수 있습니다. 피처를 숨기려면 관리자가 보안 정책의 브랜치 예외를 비활성화할 수 있습니다. GitLab.com 및 전용 GitLab에서 이 기능을 사용할 수 있습니다.

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

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

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

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

경고: GitLab 16.1 이전에 예약된 스캔 실행 정책과 직접 이관을 함께 사용하지 말아야 합니다. 직접 이관을 사용한다면, 먼저 GitLab 16.2로 업그레이드하고 시행 중인 프로젝트에서 보안 정책 봇이 활성화되어 있는지 확인하세요.

이 규칙은 지정된 cadence 필드에 정의된 일정에 따라 스캔 파이프라인을 예약하고 시행된 작업을 시행합니다. 예약된 파이프라인은 프로젝트의 .gitlab-ci.yml 파일에 정의된 다른 작업을 실행하지 않습니다. 프로젝트가 보안 정책 프로젝트에 연결되면 보안 정책 봇이 프로젝트에 생성되고 예약된 파이프라인의 작성자가 됩니다.

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

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

예약된 스캔 파이프라인은 예약된 파이프라인 작성자에 의해 트리거되는 보안 정책 봇 사용자가 프로젝트의 게스트 멤버로서 일반 사용자에게 부여된 권한을 사용하여 이 작업을 실행합니다. 보안 정책 봇 사용자는 보안 정책 프로젝트가 연결될 때 자동으로 생성되며 보안 정책 프로젝트가 해제되면 제거됩니다.

프로젝트에 보안 정책 봇 사용자가 없는 경우, 봇이 자동으로 생성되고 다음 예약된 스캔 파이프라인은 이를 사용합니다.

GitLab은 cadence 필드에 대해 다음의 CRON 구문을 지원합니다: - 지정된 시간마다 시간당 한 번씩의 일일 일정, 예: 0 18 * * * - 지정된 요일과 시간에 주 단위 일정, 예: 0 13 * * 0

참고: GitLab이 사용 중인 cron이 지원하는 경우 cadence 필드에서 CRON 구문의 다른 요소들도 작동할 수 있지만, GitLab은 공식적으로 이를 테스트하거나 지원하지 않습니다.

schedule 규칙 유형을 agents 필드와 함께 사용할 때 다음을 참고하세요: - Kubernetes 에이전트는 해당 정책이 있는지 30초마다 확인합니다. 정책이 발견되면 cadence에 따라 스캔을 실행합니다. - CRON 표현식은 Kubernetes 에이전트 팟의 시스템 시간을 사용하여 평가됩니다.

schedule 규칙 유형을 branches 필드와 함께 사용할 때 다음을 참고하세요: - cron 작업자는 15분 간격으로 실행되고 이전 15분 동안 실행되어야 할 파이프라인을 시작합니다. - 규칙에 따라 예약된 파이프라인이 최대 15분의 오프셋으로 실행되기를 기대할 수 있습니다. - CRON 표현식은 GitLab.com의 표준 UTC 시간에서 평가됩니다. 자체 관리 GitLab 인스턴스에서 서버 시간대를 변경했다면, CRON 표현식은 새로운 시간대로 평가됩니다.

`agent` 스키마

이 스키마를 사용하여 schedule rule type에서 agent 객체를 정의합니다.

필드	타입	필요 여부	설명
`namespaces`	`string`의 `array`	true	스캔되는 네임스페이스입니다. 비어있는 경우 모든 네임스페이스가 스캔됩니다.

정책 예시

- 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 네임스페이스. 빠진 경우 모든 네임스페이스가 스캔됩니다.

`scan` 액션 타입

선택된 scan이 실행될 때, 최소 하나의 규칙 조건이 충족되는 경우 추가 매개변수로 실행정책 변수 우선순위가 변경되었습니다. GitLab 16.7에서 security_policies_variables_precedence이라는 플래그와 함께 기본적으로 활성화되었습니다. GitLab 16.8에서 플래그가 제거되었습니다..

이 액션은 정의된 정책의 하나 이상의 규칙 조건이 충족될 때 선택된 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`	`string`의 `array`		정책을 위해 사용되는 러너 태그 목록입니다. 정책 작업은 지정된 태그를 가진 러너에 의해 실행됩니다.

다음 사항을 주의하세요:

선택된 보안 정책 프로젝트에 할당된 각 프로젝트에 대해 선택된 이름으로 사이트 프로필과 스캐너 프로필을 만들어야합니다. 그렇지 않으면 정책이 적용되지 않으며 대신 오류 메시지가 포함된 작업이 생성됩니다.
정책에 사이트 프로필 및 스캐너 프로필을 이름으로 연결한 후에는 수정하거나 삭제할 수 없습니다. 수정하려면 먼저 정책을 비활성화하여 active 플래그를 false로 설정해야합니다.
예약된 DAST 스캔을 구성하는 경우 보안 정책 프로젝트 저장소의 커밋 작성자는 스캐너 및 사이트 프로필에 액세스해야합니다. 그렇지 않으면 스캔이 성공적으로 예약되지 않습니다.
시크릿 감지 스캔의 경우 기본 규칙 집합으로만 지원됩니다. 사용자 정의 규칙 집합은 지원되지 않습니다. 대신 원격 구성 파일을 구성하고 SECRET_DETECTION_RULESET_GIT_REFERENCE 변수를 설정할 수 있습니다.
예약 스캔 실행 정책의 기본 설정에 따라, 정의된 CI 변수가 없는 시크릿 감지 스캔은 먼저 historic 모드로 실행됩니다 (SECRET_DETECTION_HISTORIC_SCAN = true). 이후의 예약된 스캔은 마지막 실행과 현재 SHA 사이의 커밋 범위에 SECRET_DETECTION_LOG_OPTIONS를 설정하여 기본 모드에서 실행됩니다. 스캔 실행 정책에서 제공된 CI 변수는 이 동작을 재정의할 수 있습니다. 히스토릭 모드에 대해 자세히 알아보세요.
트리거된 스캔 실행 정책의 경우, 시크릿 감지는 수동으로 .gitlab-ci.yml에서 구성된 것처럼 일반 스캔 작업과 마찬가지로 작동합니다.
파이프라인 규칙 타입에 구성된 컨테이너 스캔은 agents 객체에 정의된 에이전트를 무시합니다. agents 객체는 schedule 규칙 타입에만 고려됩니다.
스캔 실행 정책에 정의된 변수는 표준 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_DISABLED_ANALYZERS: ''
DS_DISABLED_ANALYZERS: ''
```
GitLab 버전 16.9 이전:
- CI/CD 변수에 _EXCLUDED_PATHS가 접미사로 붙은 경우, 그 값은 정책, 그룹 또는 프로젝트 CI/CD 변수에 관계없이 재정의될 수 있었습니다.
- CI/CD 변수에 _DISABLED_ANALYZERS가 접미사로 붙은 경우, 그 값은 정책, 그룹 또는 프로젝트의 정의에 관계없이 무시되었습니다.

보안 정책 프로젝트 예제

보안 정책 프로젝트에 저장된 .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
- name: 기본 브랜치 파이프라인에서 비밀 감지 및 컨테이너 스캐닝 강제 실행
  description: 이 정책은 기본 브랜치에 대해 비밀 감지 및 컨테이너 스캔을 포함하는 작업이 있는 파이프라인 구성을 강제합니다.
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
    variables:
      SAST_EXCLUDED_ANALYZERS: brakeman
  - scan: container_scanning

이 예에서:

release/* 와일드카드에 일치하는 브랜치에서 실행되는 모든 파이프라인에 대해
- DAST 스캔이 Scanner Profile A 및 Site Profile B로 실행됩니다.
매 10분마다 DAST 및 비밀 감지 스캔이 실행됩니다. DAST 스캔은 Scanner Profile C 및 Site Profile D로 실행됩니다.
main 브랜치에서 실행되는 모든 파이프라인에 대해 비밀 감지, 컨테이너 스캔 및 SAST 스캔이 실행됩니다. SAST 스캔은 SAST_EXCLUDED_ANALYZER 변수가 "brakeman"으로 설정됩니다.

스캔 실행 정책 편집기 예제

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

name: 기본 브랜치 파이프라인에서 비밀 감지 및 컨테이너 스캐닝 강제 실행
description: 이 정책은 기본 브랜치에 대해 비밀 감지 및 컨테이너 스캔을 포함하는 작업이 있는 파이프라인 구성을 강제합니다.
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"로 로컬 작업을 비활성화할 수 있습니다. 이러한 방식으로 작업을 비활성화하더라도, 스캔 실행 정책에 의해 정의된 보안 작업들은 실행되는 것을 막지 않습니다.

실험적 기능

Status: Experiment

이러한 실험적인 기능에는 다음과 같은 제한이 있습니다:

.gitlab-ci.yml이 없는 프로젝트에서 파이프라인 실행을 강제하는 것은 지원되지 않습니다.
예약된 트리거 유형에 파이프라인 실행 작업을 사용할 수 없습니다.

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

파이프라인 실행 정책 작업

전제 조건:

파이프라인 실행 정책 작업 기능을 활성화하려면, 그룹 소유자 또는 관리자가 실험적 기능을 활성화해야 합니다:
1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능을 확장합니다.
4. 보안 정책 파이프라인 실행 작업 확인란을 선택합니다.
5. 선택사항: 하위 그룹에 대해 강제를 선택합니다.
  설정이 하위 그룹에 대해 강제되지 않으면, 하위 그룹 소유자는 하위 그룹별로 설정을 관리할 수 있습니다.

파이프라인 실행 정책 작업은 대상 개발 프로젝트에서 사용자 정의 CI를 생성하고 강제하는 스캔 실행 정책에 새로운 스캔 작업 유형을 도입합니다.

이 사용자 정의 스캔 유형은 원격 CI 구성 파일을 사용하여 강제하려는 사용자 정의 CI를 정의합니다. 스캔 실행 정책은 이 파일을 프로젝트의 .gitlab-ci.yml과 병합하여 정책에 의해 강제되는 각 프로젝트에 대해 규정 준수 작업을 실행합니다.

`ci_configuration_path` 오브젝트

필드	타입	필수	설명
`project`	`string`	true	프로젝트 네임스페이스 경로입니다.
`file`	`string`	true	CI/CD YAML 파일의 파일 이름입니다.
`ref`	`string`	false	브랜치 이름, 태그 이름 또는 커밋 SHA입니다. 지정되지 않은 경우 기본 브랜치를 사용합니다.

`scan` 작업 유형

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

필드	타입	가능한 값	설명
`scan`	`string`	`custom`	작업의 유형입니다.
`ci_configuration`	`string`		문자열로 형식이 지정된 GitLab CI YAML입니다.
`ci_configuration_path`	오브젝트		CI 구성을 가리키는 프로젝트 경로 및 파일 이름이 있는 오브젝트입니다.

다음 사항을 주의하세요:

custom 스캔의 경우 ci_configuration 또는 ci_configuration_path 중 하나를 지정해야 합니다.
custom 스캔은 트리거된 규칙에 대해서만 실행됩니다.
custom 스캔에서의 작업 변수는 프로젝트의 CI/CD 구성보다 우선합니다.
파이프라인을 트리거하는 사용자는 ci_configuration_path에 지정된 CI 파일을 읽거나 CI/CD 구성에 포함된 파일에 적어도 읽기 권한이 있어야 합니다.
사용자 지정 스테이지는 사용자 정의 스캔 작업에서 stages 키워드를 사용하여 정의할 수 없습니다. 그 대신 파이프라인에 세 개의 기본 스테이지가 추가됩니다:
- .pipeline-policy-pre: .pre 스테이지 바로 앞에서, 파이프라인의 시작 부분에 있습니다.
- .pipeline-policy-test: test 스테이지 뒤에 위치합니다. test 스테이지가 없는 경우 build 스테이지 이후에 삽입됩니다. build 스테이지가 없는 경우 .pre 스테이지 바로 앞의 파이프라인 시작 부분에 삽입됩니다.
- .pipeline-policy-post: 파이프라인의 맨 끝에 위치합니다. .post 스테이지 뒤에 나옵니다.
스테이지가 없는 작업은 기본적으로 .pipeline-policy-test 스테이지에 할당됩니다.

보안 정책 프로젝트 예시

이 예시는 .gitlab/security-policies/policy.yml 파일에 사용되는 예시입니다. 이 파일은 보안 정책 프로젝트에 저장됩니다.

---
scan_execution_policy:
- name: 테스트 작업을 삽입하는 사용자 정의 스캔 생성
  description: 이 정책은 릴리스 브랜치에 대해 DAST 스캔 작업을 갖추도록 파이프라인 구성을 강화합니다.
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: custom
    ci_configuration: |-
      test job:
        stage: test
        script:
          - echo "Hello World"

이 예시에서 test job은 파이프라인의 test 스테이지에 삽입되어 Hello World를 출력합니다.

보안 정책 범위

전제 조건:

파이프라인 실행 정책 작업 기능을 활성화하려면 그룹 소유자 또는 관리자가 실험적인 기능을 활성화해야 합니다.
1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 설정 > 일반을 선택합니다.
3. 권한 및 그룹 기능을 확장합니다.
4. 보안 정책 범위 확인란을 선택합니다.
5. 선택사항. 모든 하위 그룹에서 강제로 적용을 선택합니다.
  설정이 모든 하위 그룹에 대해 강제로 적용되지 않는 경우 하위 그룹 소유자는 하위 그룹별로 설정을 관리할 수 있습니다.

보안 정책 실행은 원하는 정책을 시행하려는 그룹, 하위 그룹 또는 프로젝트와 정책을 포함하는 보안 정책 프로젝트 사이에 링크를 우선적으로 설정함으로써 수행합니다. 예를 들어 정책을 그룹에 링크하는 경우 그룹 소유자가 보안 정책 프로젝트에 대한 링크를 생성해야 합니다. 그럼 그룹 내의 모든 프로젝트에 있는 모든 정책은 보안 정책 프로젝트에서 상속됩니다.

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

규정 준수 프레임워크 라벨이 있는 프로젝트만 _포함_합니다.
선택한 프로젝트를 실행 범위에서 _포함_하거나 _제외_합니다.

정책 범위 스키마

필드	타입	필수	가능한 값	설명
`policy_scope`	`object`	false	`compliance_frameworks`, `projects`	규정 준수 프레임워크 라벨 또는 정의한 프로젝트에 기반한 정책의 범위입니다.

`policy_scope` 범위 유형

필드	타입	가능한 값	설명
`compliance_frameworks`	`object`	`ids`	실행 범위 내의 규정 준수 프레임워크의 ID 목록, `ids` 배열 형식으로 정의합니다.
`projects`	`object`	`including`, `excluding`	`excluding:` 또는 `including:`을 사용한 후, 포함하거나 제외할 프로젝트의 ID 목록을 `ids` 배열 형식으로 나열합니다.

---
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:
      ids:
      - 2
      - 11
- name: 기본 브랜치 파이프라인에서 Secret Detection 및 Container Scanning을 강제로 실행
  description: 이 정책은 기본 브랜치에 대한 파이프라인 구성에 Secret Detection 및 Container Scanning 스캔 작업이 있도록 강제합니다
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
    variables:
      SAST_EXCLUDED_ANALYZERS: brakeman
  policy_scope:
    projects:
      excluding:
        ids:
        - 24
        - 27

스캔 실행 정책

요구 사항 및 제한 사항

스캔 실행 정책 편집기

스캔 실행 정책 스키마

스캔 실행 정책 스키마

`pipeline` 규칙 유형

`schedule` 규칙 유형

`agent` 스키마

정책 예시

`scan` 액션 타입

보안 정책 프로젝트 예제

스캔 실행 정책 편집기 예제

중복 스캔 방지하기

실험적 기능

파이프라인 실행 정책 작업

`ci_configuration_path` 오브젝트

`scan` 작업 유형

보안 정책 프로젝트 예시

보안 정책 범위

정책 범위 스키마

`policy_scope` 범위 유형

도움말

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

도움받기

스캔 실행 정책

요구 사항 및 제한 사항

스캔 실행 정책 편집기

스캔 실행 정책 스키마

스캔 실행 정책 스키마

pipeline 규칙 유형

schedule 규칙 유형

agent 스키마

정책 예시

scan 액션 타입

보안 정책 프로젝트 예제

스캔 실행 정책 편집기 예제

중복 스캔 방지하기

실험적 기능

파이프라인 실행 정책 작업

ci_configuration_path 오브젝트

scan 작업 유형

보안 정책 프로젝트 예시

보안 정책 범위

정책 범위 스키마

policy_scope 범위 유형

도움말

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

도움받기

`pipeline` 규칙 유형

`schedule` 규칙 유형

`agent` 스키마

`scan` 액션 타입

`ci_configuration_path` 오브젝트

`scan` 작업 유형

`policy_scope` 범위 유형