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

스캔 실행 정책

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

- GitLab 15.2에서 도입된 그룹 수준 보안 정책 소개. - GitLab 15.4에서 GitLab.com에서 그룹 수준 보안 정책 활성화. - GitLab 15.5에서 도입된 운영 컨테이너 스캔 소개. - GitLab 16.2에서 스캔 실행 정책 편집기에서 사용자 정의 CI 변수 지원 도입. - GitLab 16.2에서 기존의 GitLab CI/CD 구성을 갖춘 프로젝트에 대해 스캔 실행 정책을 강제 적용 도입 (플래그scan_execution_policy_pipelines와 함께). 피처 플래그 scan_execution_policy_pipelines는 GitLab 16.5에서 제거되었습니다. - GitLab 16.10에서 스캔 실행 정책에서 사전 정의된 변수 재정의 도입 (플래그allow_restricted_variables_at_policy_level와 함께). 기본으로 비활성화됨.

Self-managed 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개입니다.

스캔 실행 정책 편집기

선택한 보안 정책 프로젝트를 할 수 있는 권한은 그룹, 서브그룹 또는 프로젝트 소유자에게만 부여됩니다.

정책을 완료한 후 편집기 하단의 Merge Request으로 구성을 선택하여 저장하세요. 그러면 프로젝트 구성된 보안 정책 프로젝트의 Merge Request으로 리디렉션됩니다. 프로젝트에 링크된 보안 정책 프로젝트가 없는 경우 보안 정책 프로젝트가 자동으로 만들어집니다. 기존 정책은 편집기 인터페이스 하단의 **정책 삭제를 선택하여 제거할 수 있습니다.

대부분의 정책 변경은 Merge Request이 Merge됨과 동시에 즉시 적용됩니다. 기본 브랜치에 직접 커밋되는 변경 사항은 정책 변경이 적용되기까지 최대 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`	규칙 디렉터리	true		정책이 적용되는 규칙 디렉터리.
`actions`	액션 디렉터리	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에서 일반적으로 사용 가능합니다. 플래그는 제거되었습니다.

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

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

필드	타입	필수	가능한 값	설명
`type`	`string`	true	`pipeline`	규칙의 유형.
`branches` ¹	`string`의 배열	`branch_type` 필드가없는 경우 true	`*` 또는 브랜치 이름	주어진 정책이 적용되는 브랜치(와일드카드 지원).
`branch_type` ¹	`string`	`branches` 필드가 없는 경우 true	`default`, `protected` 또는 `all`	주어진 정책이 적용되는 브랜치 유형.
`branch_exceptions`	`string`의 배열	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` ¹	`string`의 배열	`branch_type` 또는 `agents` 필드가 없는 경우 true	`*` 또는 브랜치 이름	주어진 정책이 적용되는 브랜치(와일드카드 지원).
`branch_type` ¹	`string`	`branches` 또는 `agents` 필드가 없는 경우 true	`default`, `protected` 또는 `all`	주어진 정책이 적용되는 브랜치 유형.
`branch_exceptions`	`string`의 배열	false	브랜치 이름	이 규칙에서 제외되는 브랜치들.
`cadence`	`string`	true	CRON 표현식 (예: `0 0 * * *`)	일정을 나타내는 5개의 필드로 이루어진 공백으로 구분된 문자열. `branches` 필드와 함께 사용할 경우 최소 15분 간격으로 설정됩니다.
`timezone`	`string`	false	시간대 식별자 (예: `America/New_York`)	일정에 적용할 시간대. 값은 IANA 시간대 데이터베이스 식별자여야 합니다.
`agents` ¹	`객체`	`branch_type` 또는 `branches` 필드가 없는 경우 true		GitLab 에이전트들의 이름입니다. 프로젝트에서 구성된 Kubernetes 에이전트의 이름을 키로 사용합니다.

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

예약된 스캔 파이프라인은 보안 정책 봇 사용자에 의해 트리거되며, 이는 프로젝트의 게스트 멤버이며 다음 작업을 수행할 수 있는 사용자의 권한을 가집니다. 보안 정책 봇 사용자는 보안 정책 프로젝트가 연결될 때 자동으로 생성되고, 보안 정책 프로젝트가 연결 해제될 때 자동으로 제거됩니다.

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

GitLab은 cadence 필드에서 다음과 같은 CRON 구문을 지원합니다:

특정 시간마다 1시간 단위의 일일 일정, 예를 들어: 0 18 * * *
특정 날짜와 시간에 일주일에 한 번 실행되는 주간 일정, 예를 들어: 0 13 * * 0

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

schedule 규칙 유형을 agents 필드와 함께 사용할 때 다음을 참고하십시오:

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

schedule 규칙 유형을 branches 필드와 함께 사용할 때 다음을 참고하십시오:

크론 워커는 15분 간격으로 실행되며 이전 15분 동안 실행되어야 할 모든 파이프라인을 시작합니다.
정책에 기반하여 예약된 파이프라인을 최대 15분까지 지연되어 실행할 수 있습니다.
CRON 표현식은 GitLab.com의 표준 UTC 시간에서 평가됩니다. Self-managed GitLab 인스턴스에서 서버 시간대를 변경했거나, 새로운 시간대에서 CRON 표현식을 평가해야 하는 경우, UTC 시간대에서 평가됩니다.

`에이전트` 스키마

이 스키마를 사용하여 일정 규칙 유형에서 에이전트 개체를 정의합니다.

필드	타입	필수 여부	설명
`네임스페이스`	`문자열`의 `배열`	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

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

임계치 (필수): 스캔이 실행되는 CRON 표현식
에이전트:<에이전트 이름> (필수): 스캔에 사용할 에이전트의 이름
에이전트:<에이전트 이름>:네임스페이스 (선택사항): 스캔할 쿠버네티스 네임스페이스. 생략된 경우 모든 네임스페이스가 스캔됩니다.

`스캔` 작업 유형

선택된 스캔이 해당 정책에 할당된 프로젝트의 커밋 작성자에게 스캐너 및 사이트 프로필에 대한 액세스 권한이 있어야 합니다. 그렇지 않으면 스캔이 성공적으로 예약되지 않습니다.

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

필드	타입	가능한 값	설명
`스캔`	`문자열`	`sast`, `sast_iac`, `dast`, `secret_detection`, `container_scanning`, `dependency_scanning`	작업 유형.
`사이트_프로필`	`문자열`	선택된 DAST 사이트 프로필의 이름.	실행할 DAST 스캔을 위한 DAST 사이트 프로필. 이 필드는 `scan` 유형이 `dast`인 경우에만 설정해야 합니다.
`스캐너_프로필`	`문자열` 또는 `null`	선택된 DAST 스캐너 프로필의 이름.	실행할 DAST 스캔을 위한 DAST 스캐너 프로필. 이 필드는 `scan` 유형이 `dast`인 경우에만 설정해야 합니다.
`변수`	`객체`		선택한 스캔에 적용하고 강제할 CI 변수 집합으로, `키: 값` 쌍의 배열로 제공됩니다. `키`는 변수 이름이며, 그 `값`은 문자열로 제공됩니다. 이 매개변수는 지정된 스캔에 대해 GitLab CI 작업에서 지원하는 모든 변수를 지원합니다.
`태그`	`문자열`의 `배열`		정책에 대한 러너 태그 디렉터리. 정책 작업은 지정된 태그가 있는 러너에 의해 실행됩니다.

다음 사항을 유의하세요:

선택한 보안 정책 프로젝트에 할당된 각 프로젝트에 대해 선택된 이름으로 사이트 프로필 및 스캐너 프로필을 생성해야 합니다. 그렇지 않으면 정책이 적용되지 않고 오류 메시지가 포함된 작업이 생성됩니다.
정책에서 사이트 프로필 및 스캐너 프로필을 이름으로 연결하면 수정하거나 삭제할 수 없습니다. 수정하려면 active 플래그를 false로 설정하여 먼저 정책을 비활성화해야 합니다.
예약된 DAST 스캔이 있는 정책을 구성할 때 보안 정책 프로젝트 리포지터리의 커밋 작성자는 스캐너 및 사이트 프로필에 액세스해야 합니다. 그렇지 않으면 스캔이 성공적으로 예약되지 않습니다.
시크릿 검색 스캔의 경우 기본 규칙집을 갖는 규칙만 지원됩니다. 사용자 정의 규칙집은 지원되지 않습니다. 대신, 원격 구성 파일을 구성하고 SECRET_DETECTION_RULESET_GIT_REFERENCE 변수를 설정할 수 있습니다.
기본적으로 스케줄된 스캔 실행 정책의 경우, 정책에서 정의되지 않은 CI 변수가 정의된 비밀 검색 스캔은 먼저 historic 모드에서 실행됩니다(SECRET_DETECTION_HISTORIC_SCAN = true). 이후의 모든 예약된 스캔은 SECRET_DETECTION_LOG_OPTIONS가 마지막 실행과 현재 SHA 사이의 커밋 범위로 설정된 기본 모드로 실행됩니다. 스캔 실행 정책에서 제공된 CI 변수는 이 동작을 무시할 수 있습니다. historic mode에 대해 더 알아보세요.
발생 기반 스캔 실행 정책의 경우, 시크릿 검색은 .gitlab-ci.yml에서 매뉴얼으로 구성된 일반 스캔과 동일하게 작동합니다.
파이프라인 규칙 유형에 구성된 컨테이너 스캐닝 스캔은 에이전트 객체에서 정의된 에이전트를 무시합니다. 에이전트 객체는 일정 규칙 유형에 대해서만 고려됩니다.
스캔 실행 정책에서 정의된 변수는 표준 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: 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
- 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 스캔을 실행해 보고 싶을 수 있습니다. 이 경우, 파이프라인에서 개발자의 변수로 실행되는 SAST 작업과 보안 및 준수 팀의 변수로 실행되는 SAST 작업이 두 번 실행됩니다.

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

실험 기능

Status: Experiment

이 실험적인 기능에는 제한이 있습니다:

.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
- test 스테이지 뒤에 .pipeline-policy-test 추가됩니다. test 스테이지가 존재하지 않는 경우 .build 스테이지뒤에 추가됩니다. build 스테이지가 존재하지 않는 경우, .pre 스테이지 뒤에 파이프라인의 처음에 추가됩니다.
- .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`	`제외:`, `포함:`을 사용한 다음, ID 디렉터리(`ids` 배열)을 나열합니다.

보안 정책 범위가 있는 `policy.yml` 예시

---
scan_execution_policy:
- name: 모든 릴리스 파이프라인에서 DAST 강제 실행
  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` 규칙 유형

`에이전트` 스키마

정책 예시

`스캔` 작업 유형

보안 정책 프로젝트 예시

스캔 실행 정책 편집기에 대한 예시

중복 스캔 피하기

실험 기능

파이프라인 실행 정책 액션

`ci_configuration_path` 객체

`scan` 액션 유형

보안 정책 프로젝트 예시

보안 정책 범위

정책 범위 스키마

`policy_scope` 범위 유형

보안 정책 범위가 있는 `policy.yml` 예시

도움말

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

도움받기

스캔 실행 정책

요구 사항 및 제한사항

스캔 실행 정책 편집기

스캔 실행 정책 스키마

스캔 실행 정책 스키마

pipeline 규칙 유형

schedule 규칙 유형

에이전트 스키마

정책 예시

스캔 작업 유형

보안 정책 프로젝트 예시

스캔 실행 정책 편집기에 대한 예시

중복 스캔 피하기

실험 기능

파이프라인 실행 정책 액션

ci_configuration_path 객체

scan 액션 유형

보안 정책 프로젝트 예시

보안 정책 범위

정책 범위 스키마

policy_scope 범위 유형

보안 정책 범위가 있는 policy.yml 예시

도움말

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

도움받기

`pipeline` 규칙 유형

`schedule` 규칙 유형

`에이전트` 스키마

`스캔` 작업 유형

`ci_configuration_path` 객체

`scan` 액션 유형

`policy_scope` 범위 유형

보안 정책 범위가 있는 `policy.yml` 예시