• 제한사항
• 작업
• 스캔 실행 정책 편집기
• 스캔 실행 정책 스키마
• 스캔 실행 정책 스키마
• pipeline 규칙 유형
• schedule 규칙 유형
  • Cadence
  • agent 스키마
    • 정책 예시
• scan 작업 유형
  • Scanner behavior
  • DAST 프로필
  • 스캔 설정
• CI/CD 변수
• 정책 범위 보안
  • 정책 범위 스키마
    • policy_scope 스코프 유형
    • 보안 정책 스코프를 가진 policy.yml 예제
• 보안 정책 프로젝트 예제
• 스캔 실행 정책 편집기 예제
• 중복 스캔 방지
• 실험적인 기능

스캔 실행 정책

• 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입니다. 기본적으로 활성화됩니다. 기능 플래그 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 스키마의 읽는 방법에 익숙하지 않은 경우, 다음 섹션과 표에서 다른 방법을 제공합니다.

스캔 실행 정책 스키마

• GitLab 17.4에서 도입되었습니다. scan_execution_policy_action_limit (프로젝트용) 및 scan_execution_policy_action_limit_group (그룹용)이라는 플래그로 구성됩니다. 기본 상태로 비활성화됩니다.

플래그: 이 기능의 가용성은 기능 플래그로 제어됩니다. 자세한 정보는 이력을 참조하십시오.

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

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

1. 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로 업그레이드하고 강제 적용하는 프로젝트에서 보안 정책 봇이 활성화되어 있는지 확인하십시오.

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

예약된 파이프라인:

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

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

Cadence

cadence 필드를 사용하여 정책의 작업이 실행될 시간을 예약하세요. cadence 필드는 cron 구문을 사용하지만, 일부 제한이 있습니다.

• 다음 유형의 cron 구문만 지원됩니다:
  • 지정된 시간 주변으로 매 시간 한 번씩 매일 발생하는 주기, 예: 0 18 * * *
  • 지정된 요일과 주별로 매주 한 번 발생하는 주기, 예: 0 13 * * 0
• 분과 시간에 대해 쉼표(,), 대시(-), 또는 단계 연산자(/)를 사용하는 것은 지원되지 않습니다. 이러한 문자를 사용하는 예약된 파이프라인은 건너뜁니다.

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

• GitLab SaaS의 경우 타이밍은 UTC 기준이며 GitLab Self-Managed의 경우 GitLab 호스트 시스템 시간을 기준으로 합니다. 새 정책을 테스트할 때 파이프라인이 서버의 시간대에서 예약되어 실행되지 않는 것으로 보일 수 있습니다.
• 예약된 파이프라인은 정책에서 지정된 시간 주변으로 시작하며 리소스가 사용 가능해지면 생성됩니다. 다시 말해서, 정책에서 지정된 시간과 정확히 일치하여 파이프라인이 시작되지 않을 수 있습니다.

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

• Kubernetes용 GitLab 에이전트는 해당 정책이 있는지 확인하기 위해 30초마다 확인합니다. 정책이 발견되면 cadence에 따라 스캔이 실행됩니다.
• cron 표현식은 Kubernetes 에이전트 팟의 시스템 시간을 사용하여 평가됩니다.

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

• cron 워커는 15분 간격으로 실행되며 이전 15분 동안 실행되어야 했던 모든 파이프라인을 시작합니다. 따라서 예약된 파이프라인은 최대 15분을 초과하여 실행될 수 있습니다.
• 정책이 많은 수의 프로젝트나 브랜치에서 강제로 사용되는 경우 정책은 일괄 처리되며 모든 파이프라인을 생성하는 데 시간이 걸릴 수 있습니다.

agent 스키마

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

정책 예시

- 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 Execution Policies 변수 우선순위가 기본적으로 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 Dedicated에서 프로젝트 및 그룹용 주어진 작업에 대한 보안 템플릿 선택이 사용되었습니다 (1, 2).
• GitLab 17.3에서는 프로젝트 및 그룹용 주어진 작업에 대한 보안 템플릿 선택이 GA(일반적으로 사용 가능) 상태로 되었습니다. scan_execution_policies_with_latest_templates 및 scan_execution_policies_with_latest_templates_group 플래그가 제거되었습니다.

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

참고: 프로젝트에 합병 요청 파이프라인이 활성화되어 있는 경우 각 강제 스캔에 대해 template: latest를 선택해야 합니다. 최신 템플릿을 사용하는 것은 합병 요청 파이프라인과의 호환성을 유지하기 위해 중요하며 GitLab 보안 기능을 최대한 활용할 수 있게 해줍니다. 합병 요청 파이프라인과 함께 보안 스캐닝 도구를 사용하는 자세한 내용은 보안 스캐닝 문서를 참조하세요.

Scanner behavior

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

• 정적 애플리케이션 보안 테스트 (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 매개변수에서 지원하는 다음 설정은 다음과 같습니다:

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 이전의 경우:

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

정책 범위 보안

• GitLab 16.7에 플래그이름 security_policies_policy_scope로 도입되었습니다. 기본적으로 활성화됩니다.
• GitLab 16.11에서 일반적으로 사용 가능하게 됩니다. 기능 플래그 security_policies_policy_scope가 삭제되었습니다.
• 그룹별 범위가 GitLab 17.4에서 도입되었습니다.

보안 정책이 집행되려면 먼저 다음 사이의 링크를 설정해야 합니다:

• 정책을 적용하려는 그룹, 서브그룹 또는 프로젝트
• 정책을 포함하는 보안 정책 프로젝트

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

정책 범위는 policy.yml 파일에서 범위를 설정하여 보안 정책의 다음과 같은 범주를 준수해야 합니다:

• 적용된 컴플라이언스 프레임워크가 있는 프로젝트만 포함하려면 compliance framework의 ID를 사용합니다. 프로젝트를 포함하려면 policy_scope.compliance_frameworks.id를 사용하여 프로젝트에 적용된 컴플라이언스 프레임워크 ID를 지정합니다.
• 선택된 프로젝트를 포함하거나 제외하기 위해 프로젝트의 ID를 사용합니다.
• 선택된 그룹을 포함합니다. 선택 프로젝트를 배제하기 위해 projects 객체와 함께 사용하려면 선택적으로 사용하세요.

정책 범위 스키마

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

policy_scope 스코프 유형

정책 스코프는 두 가지 유형 중 하나입니다.

보안 정책 스코프를 가진 policy.yml 예제

이 예에서 보안 정책은 다음을 수행합니다:

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

---
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: 매 10분마다 DAST 및 secret detection 스캔 강제 실행
    description: 이 정책은 매 10분마다 DAST 및 secret detection 스캔을 실행시킵니다.
    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: 모든 기본 브랜치 파이프라인에서 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
      - scan: container_scanning

이 예제에서:

• release/* 와일드카드에 해당하는 브랜치(예: 브랜치 release/v1.2.1)에서 실행되는 모든 파이프라인에 대해
  • DAST 스캔은 Scanner Profile A 및 Site Profile B로 실행됩니다.
• 매 10분마다 DAST 및 secret detection 스캔이 실행됩니다. DAST 스캔은 Scanner Profile C 및 Site Profile D로 실행됩니다.
• 기본 브랜치에서 실행되는 모든 파이프라인에 대해 Secret Detection, Container Scanning 및 SAST 스캔이 실행됩니다. SAST 스캔은 SAST_EXCLUDED_ANALYZER 변수가 "brakeman"으로 설정됩니다.

스캔 실행 정책 편집기 예제

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

name: 모든 기본 브랜치 파이프라인에서 Secret Detection 및 Container Scanning 강제 실행
description: 이 정책은 기본 브랜치에 Secret Detection 및 Container Scanning 스캔이 있는 작업을 강제하는 파이프라인 구성을 시행합니다.
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"로 로컬 작업을 비활성화할 수 있습니다. 이 방법으로 작업을 비활성화하더라도 스캔 실행 정책에서 정의한 보안 작업은 실행되지 않습니다.

실험적인 기능

이 실험은 종료되었으며 계속되지 않을 것입니다. 이 실험의 피드백을 받은 후, 새로운 사용자 정의 CI 시행을 위한 새로운 정책 유형에 중점을 두고 노력할 것입니다. 이 실험은 17.3에서 제거될 것입니다.

pipeline 실행 정책에 대해 자세히 알아보세요.