작업
스캔 실행 정책 편집기
스캔 실행 정책 스키마
스캔 실행 정책 스키마
파이프라인 규칙 유형
schedule rule type
- agent 스키마
  - 정책 예시
scan 액션 유형
보안 정책 범위
- 정책 범위 스키마
  - policy_scope 범위 유형
  - 보안 정책 범위가 포함된 policy.yml 예제
보안 정책 예시 프로젝트
스캔 실행 정책 에디터 예시
중복 스캔 방지
실험적 기능
- 파이프라인 실행 정책 액션

스캔 실행 정책

Tier: Ultimate Offering: GitLab.com, Self-Managed형, GitLab Dedicated

그룹 수준 보안 정책은 GitLab 15.2에서 소개되었습니다.
그룹 수준 보안 정책은 GitLab 15.4에서 GitLab.com에서 활성화되었습니다.
운영 컨테이너 스캔은 GitLab 15.5에서 도입되었습니다.
스캔 실행 정책 편집기에서 사용자 정의 CI 변수를 지원 도입되었습니다 in GitLab 16.2.
기존 GitLab CI/CD 구성이 있는 프로젝트에서 스캔 실행 정책을 강제로 적용 도입되었습니다 in GitLab 16.2 특징 플래그인 scan_execution_policy_pipelines와 함께. 특징 플래그scan_execution_policy_pipelines가 GitLab 16.5에서 제거되었습니다.
스캔 실행 정책에서 사전 정의된 변수 무시 도입되었습니다 in GitLab 16.10 특징 플래그인 allow_restricted_variables_at_policy_level와 함께. 기본적으로 활성화됨.

보안 스캔을 강제로 실행 정책을 사용하여 파이프라인의 일부로 또는 지정된 일정에 보안 스캔을 실행합니다. 보안 스캔은 그룹 또는 하위 그룹 수준에서 정책을 정의하는 경우 프로젝트 파이프라인에서 여러 번 실행됩니다.

스캔 실행 정책은 모든 해당 프로젝트에 대해 강제로 적용됩니다. .gitlab-ci.yml 파일이 없는 프로젝트이거나 AutoDevOps가 비활성화된 경우에도 보안 정책은 암시적으로 .gitlab-ci.yml 파일을 생성합니다. 이는 프로젝트에서 빌드가 필요하지 않은 시크릿 감지, 정적 분석 또는 다른 스캐너의 실행을 가능하게 합니다.

이 기능은 컴플라이언스 프레임워크 파이프라인과 겹치는 부분이 있습니다. 두 기능에 대한 사용자 경험을 통합하지 않았기 때문에 두 기능간의 유사성과 차이에 대한 자세한 내용은 확인하세요.

비디오 안내는 GitLab에서 보안 스캔 정책 설정하는 방법을 참조하십시오.
개요는 GitLab CI/CD 구성 없이 프로젝트에 스캔 실행 정책을 강제로 적용하는 방법을 참조하십시오.

작업

DAST 스캔을 제외한 스캔에 대한 정책 작업은 파이프라인의 test 단계에 생성됩니다. 기본 파이프라인에서 test 단계를 제거하면 작업은 대신 scan-policies 단계에서 실행됩니다. 이 단계는 파이프라인에 주입되는 것으로, 평가 시에 없는 경우에 주입됩니다. build 단계가 있는 경우, build 단계 바로 뒤에 삽입되며, 그렇지 않으면 파이프라인의 맨 처음에 삽입됩니다. DAST 스캔은 항상 dast 단계에서 실행됩니다. 이 단계가 없는 경우 파이프라인의 끝에 dast 단계가 주입됩니다.

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

스캔 실행 정책 편집기

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

전제 조건:

그룹, 하위 그룹 또는 프로젝트 소유자만이 권한을 가지고 보안 정책 프로젝트를 선택할 수 있습니다.
보안 실행 정책 당 최대 5개의 스캔 실행 정책을 구성할 수 있습니다.

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

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

DAST 실행 정책에 대한 규칙 모드 편집기를 사용하여 프로필, 사이트의 선택은 프로젝트 또는 그룹 수준에 따라 다릅니다. 프로젝트 수준 정책의 경우, 규칙 모드 편집기는 프로젝트에서 이미 정의된 프로필을 선택할 수 있는 디렉터리을 제공합니다. 그룹 수준 정책의 경우, 사용할 프로필의 이름을 입력해야 하며, 파이프라인 오류를 방지하기 위해 동일한 이름의 프로필이 그룹의 모든 프로젝트에 존재해야 합니다.

스캔 실행 정책 스키마

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

새로운 정책을 저장할 때, GitLab은 이 JSON 스키마를 통해 정책 내용을 유효성 검사합니다. JSON 스키마 읽는 방법을 잘 모르는 경우, 다음 섹션 및 표에서 대안을 제공합니다.

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

스캔 실행 정책 스키마

필드	유형	필수	가능한 값	설명
`name`	문자열	true		정책 이름. 최대 255자.
`description` (선택사항)	문자열	true		정책 설명.
`enabled`	부울	true	`true`, `false`	정책을 활성화(`true`) 또는 비활성화(`false`)하는 플래그.
`rules`	규칙의 배열	true		정책을 적용하는 규칙의 디렉터리.
`actions`	작업의 배열	true		정책이 강제하는 작업의 디렉터리.

`파이프라인` 규칙 유형

branch_type 필드는 GitLab 16.1에서 소개되었으며, security_policies_branch_type라는 특징 플래그와 함께 제공되었습니다. GitLab 16.2에서 일반적으로 사용 가능합니다. 특징 플래그는 제거되었습니다.
branch_exceptions 필드는 GitLab 16.3에서 소개되었으며, security_policies_branch_exceptions라는 특징 플래그와 함께 제공되었습니다. GitLab 16.5에서 일반적으로 사용 가능합니다. 특징 플래그는 제거되었습니다.

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

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

필드	유형	필수	가능한 값	설명
`type`	문자열	true	`pipeline`	규칙의 유형.
`branches` ¹	`string`의 배열	`branch_type` 필드가 없으면 필요	`*` 또는 브랜치 이름	해당 정책이 적용되는 브랜치(와일드카드 지원).
`branch_type` ¹	문자열	`branches` 필드가 없으면 필요	`default`, `protected` 또는 `all`	해당 정책이 적용되는 브랜치의 유형.
`branch_exceptions`	문자열의 배열	선택적	브랜치 이름	이 규칙에서 제외할 브랜치의 이름.

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

`schedule` rule type

branch_type 필드는 GitLab 16.1에서 도입되었습니다 GitLab 16.2에서 security_policies_branch_type이라는 플래그와 함께. GitLab 16.2에서 일반적으로 사용 가능하게 됐습니다. 피처 플래그 삭제됨.
branch_exceptions 필드는 GitLab 16.3에서 도입되었습니다 GitLab 16.5에서 security_policies_branch_exceptions라는 플래그와 함께. GitLab 16.5에서 일반적으로 사용 가능하게 됐습니다. 피처 플래그 삭제됨.

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

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

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

필드	유형	필수	가능한 값	설명
`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`)	cadence에 적용할 시간대. 값은 IANA 시간대 데이터베이스 식별자여야 합니다.
`agents` ¹	`object`	`branch_type` 또는 `branches` 필드 중 하나라도 존재하지 않으면 true		GitLab 에이전트의 이름과 Operational Container Scanning이 실행되는 GitLab 에이전트의 이름. 객체 키는 GitLab에서 프로젝트에 구성된 쿠버네티스 에이전트의 이름입니다.

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

예약된 스캔 파이프라인은 보안 정책 프로젝트에 연결된 게스트 멤버인 보안 정책 봇 사용자에 의해 트리거됩니다. 보안 정책 봇 사용자는 자동으로 만들어지고 보안 정책 프로젝트에 링크가 제거되면 제거됩니다. 프로젝트에 보안 정책 봇 사용자가 없는 경우, 해당 봇은 자동으로 만들어지며 예약된 스캔 파이프라인이 그 봇을 사용합니다.

GitLab은 cadence 필드에 대해 다음과 같은 CRON 구문 유형을 지원합니다:

지정된 시간을 기준으로 매 시간 한 번씩 일일 스케줄
지정된 요일과 시간에 일주일에 한 번씩 주간 스케줄

만일 cron의 구현에서 지원한다면 cadence 필드의 CRON 구문의 다른 요소들이 작동할 수 있겠지만, GitLab에서는 공식적으로 테스트하거나 지원하지 않습니다. 쉼표 (,), 하이픈 (-) 또는 단계 연산자 (/)는 분과 시간에 대해 지원되지 않습니다. 정책을 만들 때 cadence가 유효하지 않으면 오류가 표시됩니다. 금시 또는 시간 필드에 쉼표 (,), 하이픈 (-), 또는 스텝 연산자 (/)를 사용한 이전에 만든 정책의 예약된 파이프라인은 건너뜁니다. 이전에 예약된 파이프라인은 지정된 시간에 새 파이프라인을 생성하기 위해 cadence 값을 사용합니다. 지정된 시간에 리소스가 사용 가능해지면 파이프라인이 실행됩니다.

schedule 규칙 유형을 agents 필드와 함께 사용할 때 다음 사항을 유의하세요:

쿠버네티스 에이전트는 적용 가능한 정책을 찾기 위해 30초마다 확인합니다. 정책을 찾으면 CRON 표현식에 따라 스캔이 실행됩니다.
CRON 표현식은 쿠버네티스 에이전트 pod의 시스템 시간을 사용하여 평가됩니다.

schedule 규칙 유형과 branches 필드를 함께 사용할 때 다음 사항을 유의하세요:

크론 워커는 15분 간격으로 실행되며 직전 15분 동안에 실행되어야 했던 파이프라인을 시작합니다.
규칙에 따라 예약된 파이프라인이 최대 15분까지 차이가 있을 수 있습니다.
대규모 프로젝트나 브랜치에 정책이 시행되는 경우 일괄 처리로 처리되며 모든 파이프라인을 생성하는 데 시간이 걸릴 수 있습니다.
CRON 표현식은 GitLab.com의 표준 UTC 시간에서 평가됩니다. Self-Managed형 GitLab 인스턴스에서 서버 시간대를 변경했다면 CRON 표현식이 새로운 시간대로 평가됩니다.

`agent` 스키마

schedule 규칙 유형에서 agents 객체를 정의하는 데 이 스키마를 사용하세요.

필드	유형	필수	설명
`namespaces`	`array` of `string`	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 (선택사항): 스캔할 쿠버네티스 네임스페이스. 생략하면 모든 네임스페이스가 스캔됩니다.

`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`	`array` of `string`		정책에 대한 러너 태그 디렉터리입니다. 정책 작업은 지정된 태그가 있는 러너에 의해 실행됩니다.

다음 사항을 주의하세요:

선택한 Security Policy Project에 할당된 각 프로젝트에 대해 선택한 이름으로 사이트 프로필 및 스캐너 프로필을 생성해야 합니다. 그렇지 않으면 정책이 적용되지 않고 오류 메시지가 포함된 작업이 생성됩니다.
정책에서 사이트 프로필 및 스캐너 프로필을 이름으로 연결한 후에는 이를 수정하거나 삭제할 수 없습니다. 수정하려면 먼저 active 플래그를 false로 설정하여 정책을 비활성화해야 합니다.
예약된 DAST 스캔으로 정책을 구성할 때, 보안 정책 프로젝트의 리파지토리에 커밋한 작성자는 스캐너 및 사이트 프로필에 액세스해야 합니다. 그렇지 않으면 스캔이 성공적으로 예약되지 않습니다.
비밀 탐지 스캔의 경우 기본 규칙 집합으로만 규칙이 지원됩니다. 사용자 정의 규칙 집합은 지원되지 않습니다. 대안으로 원격 구성 파일을 구성하고 SECRET_DETECTION_RULESET_GIT_REFERENCE 변수를 설정할 수 있습니다.
기본적으로 예약된 스캔 실행 정책의 경우에는 정의된 CI 변수가 없는 비밀 탐지 스캔이 먼저 historic 모드에서 실행됩니다 (SECRET_DETECTION_HISTORIC_SCAN = true). 이후의 예약된 스캔은 모두 기본 모드에서 SECRET_DETECTION_LOG_OPTIONS가 마지막 실행 및 현재 SHA 사이의 커밋 범위로 설정됩니다. 스캔 실행 정책에서 제공된 CI 변수는 이 동작을 재정의할 수 있습니다. historic mode에 대해 자세히 알아보기.
triggered 스캔 실행 정책의 경우 비밀 탐지는 .gitlab-ci.yml에서 매뉴얼으로 구성한 것처럼 정상적으로 작동합니다.
파이프라인 규칙 유형으로 구성된 컨테이너 스캐닝 스캔은 agents 객체에 정의된 에이전트를 무시합니다. agents 객체는 schedule 규칙 유형에만 고려됩니다. agents에 제공된 이름을 가진 에이전트는 프로젝트에 생성하고 구성해야 합니다.
스캔 실행 정책에서 정의된 변수는 표준 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 및 이전 버전:
- _EXCLUDED_PATHS로 끝나는 CI/CD 변수가 정책에서 선언된 경우, 값은 그룹 또는 프로젝트 CI/CD 변수에 의해 재정의될 수 있었습니다.
- _DISABLED_ANALYZERS로 끝나는 CI/CD 변수가 정책에서 선언된 경우, 정책, 그룹, 또는 프로젝트에 정의된 값을 무시했습니다.

보안 정책 범위

GitLab 16.7에서 security_policies_policy_scope라는 플래그가 지정되어 도입되었습니다. 기본적으로 활성화됩니다.
GitLab 16.11에서 일반적으로 사용 가능하게 되었습니다. 피처 플래그 security_policies_policy_scope가 제거되었습니다.

보안 정책 강제는 먼저 정책을 포함하는 그룹, 서브그룹 또는 프로젝트와 정책을 포함하는 보안 정책 프로젝트 사이의 링크를 설정함으로써 가능합니다. 예를 들어, 정책을 그룹에 링크하려면 그룹 소유자가 보안 정책 프로젝트에 대한 링크를 생성해야 합니다. 그런 다음, 보안 정책 프로젝트의 모든 정책이 그룹의 모든 프로젝트에 상속됩니다.

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

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

정책 범위 스키마

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

`policy_scope` 범위 유형

필드	타입	가능한 값	설명
`compliance_frameworks`	`array`		범위 적용의 규정 준수 프레임워크 ID 디렉터리입니다. `id` 키를 가진 객체 배열입니다.
`projects`	`object`	`including`, `excluding`	`excluding:` 또는 `including:`을 사용한 다음, 포함하거나 제외할 프로젝트의 ID 디렉터리을 객체 배열로 나열합니다.

보안 정책 범위가 포함된 `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
  policy_scope:
    compliance_frameworks:
      - id: 2
      - id: 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:
        - 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: DAST 및 시크릿 탐지 스캔을 10분마다 강제 실행
  description: 이 정책은 DAST 및 시크릿 탐지 스캔을 10분마다 실행하도록 강제합니다.
  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로 실행됩니다.
DAST 및 시크릿 탐지 스캔은 10분마다 실행됩니다. 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 작업이 실행되고, 보안 및 규정 준수팀 변수로 다른 SAST 작업이 실행됩니다.

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

실험적 기능

상태: 실험

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

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

실험적인 기능에 대한 의견이 있으신가요? 의견을 듣고 싶습니다! 이에 대한 의견을 피드백 이슈에서 공유해 주세요.

파이프라인 실행 정책 액션

전제 조건:

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

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

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

`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 파일을 읽을 수 있는 최소한의 읽기 권한이 있어야 합니다.
사용자 정의 스캔 액션에 stages 키워드를 사용하여 사용자 정의 단계를 정의할 수 없습니다. 대신에 세 가지 예약된 단계가 파이프라인에 추가됩니다:
- .pipeline-policy-pre: .pre 단계 바로 앞에 위치합니다.
- .pipeline-policy-test: test 단계 뒤에 위치합니다. test 단계가 없는 경우 .post 단계 이후에 위치합니다. build 단계가 없는 경우 .pre 단계 바로 앞에 위치합니다.
- .pipeline-policy-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"

스캔 실행 정책

작업

스캔 실행 정책 편집기

스캔 실행 정책 스키마

스캔 실행 정책 스키마

`파이프라인` 규칙 유형

`schedule` rule type

`agent` 스키마

정책 예시

`scan` 액션 유형

보안 정책 범위

정책 범위 스키마

`policy_scope` 범위 유형

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

보안 정책 예시 프로젝트

스캔 실행 정책 에디터 예시

중복 스캔 방지

실험적 기능

파이프라인 실행 정책 액션

`ci_configuration_path` 객체

`scan` 액션 유형

보안 정책 예시 프로젝트

도움말

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

도움받기

스캔 실행 정책

작업

스캔 실행 정책 편집기

스캔 실행 정책 스키마

스캔 실행 정책 스키마

파이프라인 규칙 유형

schedule rule type

agent 스키마

정책 예시

scan 액션 유형

보안 정책 범위

정책 범위 스키마

policy_scope 범위 유형

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

보안 정책 예시 프로젝트

스캔 실행 정책 에디터 예시

중복 스캔 방지

실험적 기능

파이프라인 실행 정책 액션

ci_configuration_path 객체

scan 액션 유형

보안 정책 예시 프로젝트

도움말

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

도움받기

`파이프라인` 규칙 유형

`schedule` rule type

`agent` 스키마

`scan` 액션 유형

`policy_scope` 범위 유형

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

`ci_configuration_path` 객체

`scan` 액션 유형