파이프라인 시크릿 검색

Tier: Free Offering: GitLab.com Status: Experimental

파이프라인 시크릿 검색은 GitLab에 푸시된 후에 커밋된 파일을 스캔합니다.

파이프라인 시크릿 검색을 활성화한 후에는 CI/CD 작업인 secret_detection에서 스캔이 실행됩니다. 모든 GitLab 티어에서 파이프라인 시크릿 검색 JSON 보고서 아티팩트를 실행하고 볼 수 있습니다.

GitLab Ultimate을 사용하면 파이프라인 시크릿 검색 결과가 다음과 같이 처리됩니다:

이 파이프라인 시크릿 검색 설명서의 대화식 독해 및 사용 방법 데모를 보려면 아래를 참조하세요:

다른 대화식 독해 및 사용 방법 데모를 보려면 GitLab 응용 프로그램 보안 플레이리스트 시작하기를 참조하세요.

검색된 시크릿

GitLab은 파이프라인 시크릿 검색에서 사용하는 감지 규칙을 유지합니다. 기본 규칙 세트에는 100개 이상의 패턴이 포함되어 있습니다.

대부분의 파이프라인 시크릿 검색 패턴은 특정 유형의 시크릿을 찾습니다. 많은 서비스에서는 누설될 경우 식별할 수 있도록 시크릿에 접두사나 다른 구조적 세부 정보를 추가합니다. 예를 들어, GitLab은 기본적으로 프로젝트, 그룹 및 개인 액세스 토큰에 glpat- 접두사를 추가합니다.

더 신뢰할 수 있고 높은 신뢰도의 결과를 제공하기 위해 파이프라인 시크릿 검색은 URL과 같은 특정 컨텍스트에서만 패스워드 또는 다른 구조화되지 않은 시크릿을 찾습니다.

커버리지

파이프라인 시크릿 검색은 상황에 따라 코드의 다양한 측면을 스캔합니다. “기본 브랜치”를 제외한 모든 메소드의 경우, 파이프라인 시크릿 검색은 작업 트리가 아닌 커밋을 스캔합니다. 예를 들어, 파이프라인 시크릿 검색은 하나의 커밋에 시크릿이 추가되고 이후 커밋에서 제거되었는지 여부를 감지할 수 있습니다.

  • 히스토리 스캔

    SECRET_DETECTION_HISTORIC_SCAN 변수가 설정되어 있는 경우, 모든 브랜치의 내용이 스캔됩니다. 리포지터리의 내용을 스캔하기 전에 파이프라인 시크릿 검색은 git fetch --all 명령을 실행하여 모든 브랜치의 내용을 가져옵니다.

  • 커밋 범위

    SECRET_DETECTION_LOG_OPTIONS 변수가 설정되어 있는 경우, 시크릿 분석기는 실행 중인 파이프라인의 브랜치 또는 참조의 전체 히스토리를 가져옵니다. 그런 다음에 파이프라인 시크릿 검색이 지정된 커밋 범위를 스캔합니다.

  • 기본 브랜치

    파이프라인 시크릿 검색이 기본 브랜치에서 실행되면 Git 리포지터리는 일반 폴더로 처리됩니다. 리포지터리의 현재 HEAD의 내용만 스캔됩니다. 커밋 기록은 스캔되지 않습니다.

  • 푸시 이벤트

    푸시 이벤트에서, 파이프라인 시크릿 검색은 러너에서 제공되는 정보를 기반으로 스캔할 커밋 범위를 결정합니다. 커밋 범위를 결정하기 위해 CI_COMMIT_SHA와 CI_COMMIT_BEFORE_SHA 변수가 중요합니다.

    • CI_COMMIT_SHA는 특정 브랜치의 HEAD에 대한 커밋입니다. 이 변수는 항상 푸시 이벤트에 대해 설정됩니다.
    • CI_COMMIT_BEFORE_SHA는 대부분의 경우에 설정됩니다. 그러나 새 브랜치에 대한 첫 번째 푸시 이벤트나 Merge 파이프라인의 경우에는 설정되지 않습니다. 따라서 파이프라인 시크릿 검색은 새 브랜치에 여러 커밋이 커밋되는 경우에는 보장할 수 없습니다.

  • Merge Request

    Merge Request에서 파이프라인 시크릿 검색은 원본 브랜치에서 수행된 모든 커밋을 스캔합니다. 이 기능을 사용하려면 최신 파이프라인 시크릿 검색 템플릿을 사용해야 합니다. Merge Request 파이프라인을 지원하므로 파이프라인 시크릿 검색의 결과는 파이프라인이 완료된 후에만 사용할 수 있습니다.

전체 히스토리 파이프라인 시크릿 검색

기본적으로 파이프라인 시크릿 검색은 Git 리포지터리의 현재 상태만 스캔합니다. 리포지터리 히스토리에 포함된 시크릿은 감지되지 않습니다. 이를 해결하기 위해 파이프라인 시크릿 검색은 Git 리포지터리의 전체 히스토리를 스캔할 수 있습니다.

파이프라인 시크릿 검색을 활성화한 후에는 전체 히스토리 스캔을 한 번만 실행해야 합니다. 특히 Git 히스토리가 긴 대형 리포지터리인 경우 전체 히스토리 스캔에는 오랜 시간이 소요될 수 있습니다. 초기 전체 히스토리 스캔을 완료한 후에는 파이프라인의 일부로 표준 파이프라인 시크릿 검색만 사용하세요.

설정

요구 사항

필수 컴포넌트:

  • docker 또는 kubernetes 실행자를 사용하는 Linux 기반 GitLab 러너. GitLab.com의 공유 러너를 사용하는 경우, 기본적으로 이러한 설정이 활성화됩니다.
    • Windows 러너는 지원되지 않습니다.
    • amd64 이외의 CPU 아키텍처는 지원되지 않습니다.
  • 자체 러너를 사용하는 경우, 설치된 Docker 버전이 19.03.0이 아닌지 확인하세요. 자세한 내용은 문제 해결 정보를 참조하세요.
  • GitLab CI/CD 구성 (.gitlab-ci.yml)에 test 단계가 포함되어 있어야 합니다.

다양한 GitLab 티어에서 다양한 기능을 사용할 수 있습니다.

기능 무료 및 Premium에서 사용 가능 Ultimate에서 사용 가능
파이프라인 시크릿 검색 스캐너 설정 가능 가능
파이프라인 시크릿 검색 설정 사용자 정의 가능 가능
SAST 출력 다운로드 가능 가능
글이 게시되기 전에 잠재적인 시크릿에 대한 경고 확인 가능 가능
Merge Request 위젯에서 새로운 발견 보기 불가능 가능
파이프라인의 보안 탭에서 식별된 시크릿 보기 불가능 가능
취약점 관리 불가능 가능
보안 대시보드에 액세스 불가능 가능
파이프라인 시크릿 검색 규칙 집합 사용자 정의 불가능 가능

분석기 활성화

파이프라인 시크릿 감지를 활성화하려면 다음 중 하나를 수행하십시오:

.gitlab-ci.yml 파일을 매뉴얼으로 편집

이 방법은 기존 .gitlab-ci.yml 파일을 매뉴얼으로 편집해야합니다. GitLab CI/CD 구성 파일이 복잡한 경우에 사용하십시오.

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. Build > 파이프라인 편집기를 선택합니다.

  3. 다음을 .gitlab-ci.yml 파일 끝에 복사하여 붙여넣기합니다: 

    include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  4. 유효성 검사 탭을 선택한 다음 파이프라인 유효성 검사를 선택합니다. 메시지 시뮬레이션이 성공적으로 완료되었습니다는 파일이 유효함을 나타냅니다.
  5. 편집 탭을 선택합니다.
  6. 선택 사항. 커밋 메시지 텍스트 상자에 커밋 메시지를 사용자 정의합니다.
  7. 브랜치 텍스트 상자에 기본 브랜치의 이름을 입력합니다.
  8. 변경 사항 커밋을 선택합니다.

이제 파이프라인에 파이프라인 시크릿 감지 작업이 포함됩니다.

자동으로 구성된 Merge Request 사용

  • GitLab 13.11에 도입되었으며, 기본적으로 활성화된 특성 플래그 뒤에 배포되었습니다.
  • GitLab 14.1에서 특성 플래그가 제거되었습니다.

이 방법은 파이프라인 시크릿 감지 템플릿이 .gitlab-ci.yml 파일에 포함된 Merge Request을 자동으로 준비합니다. 그런 다음 Merge Request을 Merge하여 파이프라인 시크릿 감지를 활성화합니다.

note
이 방법은 기존 .gitlab-ci.yml 파일이 없거나 최소 구성 파일로 사용할 때 가장 적합합니다. GitLab 구성 파일이 복잡한 경우 성공적으로 구문 분석되지 않을 수 있으며 에러가 발생할 수 있습니다. 그 경우 매뉴얼 방법을 대신 사용하십시오.

파이프라인 시크릿 감지를 활성화하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. Secure > 보안 구성을 선택합니다.
  3. Pipeline Secret Detection 행에서 Merge Request으로 구성을 선택합니다.
  4. 선택 사항. 필드를 입력합니다.
  5. Merge Request 생성을 선택합니다.
  6. Merge Request을 검토하고 Merge합니다.

이제 파이프라인에 파이프라인 시크릿 감지 작업이 포함됩니다.

분석기 설정 사용자화

파이프라인 시크릿 감지 스캔 설정은 .gitlab-ci.yml을 사용하여 CI/CD 변수를 통해 변경할 수 있습니다.

caution
GitLab 보안 스캔 도구의 모든 구성은 기본 브랜치로의 Merge 전에 Merge Request에서 테스트해야 합니다. 이를 하지 않으면 예상치 못한 결과가 발생할 수 있으며, 잘못된 양성 결과가 발생할 수 있습니다.

새 패턴 추가

고객 리포지터리에서 다른 유형의 시크릿을 검색하려면 사용자 정의 규칙 집합을 구성할 수 있습니다.

파이프라인 시크릿 감지의 모든 사용자를 위한 새로운 감지 규칙을 제안하려면 기본 규칙을 포함하는 파일에 대한 Merge Request을 생성하십시오.

클라우드 또는 SaaS 제품을 운영하고 GitLab과 협력하여 사용자를 보호하는 데 관심이 있는 경우 유출 자격 증명 알림을 위한 파트너 프로그램에 대해 자세히 알아보세요.

시크릿 무시하기

일부 경우에는 비밀을 무시하고 싶을 수 있습니다. 예를 들어 테스트 수트에서 가짜 비밀을 가지고 있을 수 있습니다. 이 경우에는 비밀을 무시하고 취약성으로 보고받지 않으려고 합니다.

비밀을 무시하려면 비밀이 포함된 라인에 주석으로 gitleaks:allow를 추가하십시오.

예: 

 "GitLab의 개인 토큰은 glpat-JUST20LETTERSANDNUMB과 같이 보일 것입니다." #gitleaks:allow

특정 분석기 버전 고정하기

GitLab 관리 CI/CD 템플릿은 주 버전을 지정하고 해당 주 버전 내에서 최신 분석기 릴리스를 자동으로 가져옵니다.

경우에 따라 특정 버전을 사용해야 하는 경우가 있습니다. 예를 들어, 나중 릴리스에서의 회귀를 피해야 하는 경우가 있습니다.

자동 업데이트 동작을 재정의하려면 CI/CD 구성 파일에서 SECRETS_ANALYZER_VERSION CI/CD 변수를 설정하십시오. 이 변수를 포함한 후 Secret-Detection.gitlab-ci.yml 템플릿을 추가하십시오.

태그를 다음으로 설정할 수 있습니다:

  • 4와 같은 주 버전. 파이프라인은 해당 주 버전 내에서 릴리스된 모든 마이너 또는 패치 업데이트를 사용합니다.
  • 4.5와 같은 마이너 버전. 파이프라인은 해당 마이너 버전 내에서 릴리스된 모든 패치 업데이트를 사용합니다.
  • 4.5.0과 같은 패치 버전. 파이프라인에는 업데이트가 적용되지 않습니다.

다음은 특정 마이너 버전의 분석기를 사용하는 예시입니다: 

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

secret_detection:
  variables:
    SECRETS_ANALYZER_VERSION: "4.5"

기본 구성 확장하기

필수 조작 확장 지원을 사용하여 기본 구성을 추가 변경할 수 있습니다.

다음 파일 예시에서 file을 통해 파이프라인 시크릿 감지에서 무시될 문자열 glpat-1234567890abcdefghij를 정의합니다. 이 GitLab 개인 액세스 토큰(PAT)은 테스트 케이스에서 사용됩니다. 이를 감지하는 것은 잘못된 양성으로 처리됩니다.

secret-detection-ruleset.toml 파일은 extended-gitleaks-config.toml 파일을 포함하도록 정의합니다. extended-gitleaks-config.toml 파일은 사용자 지정 Gitleaks 구성을 정의합니다. allowlist 섹션은 무시할 비밀을 일치시키는 정규식을 정의합니다.

.gitlab/secret-detection-ruleset.toml

[secrets] description = ‘비밀 커스텀 규칙 구성’

[[secrets.passthrough]] type = “file” target = “gitleaks.toml” value = “extended-gitleaks-config.toml” ``` 

### extended-gitleaks-config.toml
title = "gitlab의 기본 gitleaks 구성의 확장"

[extend]
### 기본 패키지 경로 확장
path = "/gitleaks.toml"

[allowlist]
  description = "검출에서 무시할 테스트 토큰의 허용 디렉터리"
  regexTarget = "match"
  regexes = [
    '''glpat-1234567890abcdefghij''',
  ]

전체 히스토리 파이프라인 시크릿 검출 사용

전체 히스토리 파이프라인 시크릿 검출을 사용하려면 .gitlab-ci.yml 파일에서 변수 SECRET_DETECTION_HISTORIC_SCAN을 true로 설정하세요.

Merge Request 파이프라인에서 작업 실행

Merge Request 파이프라인에서 보안 스캐닝 도구 사용을 참조하세요.

사용자 지정 규칙 세트

Tier: Ultimate

GitLab UI에서 보고된 시크릿을 사용자 정의할 수 있지만, secret_detection 작업 로그에는 항상 기본 파이프라인 시크릿 검출 규칙에 의해 검출된 시크릿의 수가 포함됩니다.

다음 사용자 정의 옵션은 별도로 또는 조합하여 사용할 수 있습니다:

사용자 정의 구성 합성

파이프라인 시크릿 검출 규칙세트를 재정의하기 위해 passthrough를 사용할 수 있습니다. secrets 분석기에서 다음 passthrough 유형이 지원됩니다:

  • raw
  • file

passthrough를 정의하려면 다음 중 하나를 secret-detection-ruleset.toml 파일에 추가하세요:

  • 인라인(raw) 값 사용: 

    [secrets]
  description = '비밀 커스텀 규칙 구성'
    
  [[secrets.passthrough]]
    type  = "raw"
    target = "gitleaks.toml"
    value = """\
title = "gitleaks config"
### regexes를 regex 테이블에 추가하세요
[[rules]]
description = "Test for Raw Custom Rulesets"
regex = '''Custom Raw Ruleset T[est]{3}'''
"""

  • 현재 리포지터리에 커밋된 외부 file 사용: 

    [secrets]
  description = '비밀 커스텀 규칙 구성'
    
  [[secrets.passthrough]]
    type  = "file"
    target = "gitleaks.toml"
    value = "config/gitleaks.toml"

passthrough 구문에 대한 구문법은 SAST 사용자 정의 규칙세트 페이지를 참조하세요.

원격 구성 파일 지정

프로젝트는 CI/CD 변수를 구성하여 현재 리포지터리 외부의 규칙세트 구성을 지정할 수 있습니다.

SECRET_DETECTION_RULESET_GIT_REFERENCE 변수는 URI, 선택적 인증, 선택적 Git SHA를 지정하는 SCP 스타일 구문을 사용합니다. 변수는 다음 형식을 사용합니다: 

<AUTH_USER>:<AUTH_PASSWORD>@<PROJECT_PATH>@<GIT_SHA>
note
프로젝트 내의 로컬 .gitlab/secret-detection-ruleset.toml 파일이 SECRET_DETECTION_RULESET_GIT_REFERENCE보다 우선합니다.

다음 예는 프로젝트에 Pipeline Secret Detection 템플릿을 포함하고 별도 프로젝트 구성을 참조하기 위해 SECRET_DETECTION_RULESET_GIT_REFERENCE 변수를 지정하는 방법을 보여줍니다. 

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

variables:
  SECRET_DETECTION_RULESET_GIT_REFERENCE: "gitlab.com/example-group/example-ruleset-project"

원격 구성 구문법에 대한 자세한 내용은 SAST 사용자 정의 규칙세트 페이지의 개인 원격 구성 지정 예를 참조하세요.

분석기 작업 재정의

작업을 재정의하려면(variables 또는 dependencies와 같은 속성 변경) 해당 작업과 동일한 이름의 작업을 재선언하세요. 이 새로운 작업은 템플릿 포함 이후에 배치되며 추가 키를 지정하세요.

다음 예제는 .gitlab-ci.yml 파일의 일부입니다:

  • 포함된 Pipeline Secret Detection 템플릿.
  • secret_detection 작업에서 CI/CD 변수 SECRET_DETECTION_HISTORIC_SCAN을 true로 설정합니다. 템플릿은 파이프라인 구성 이전에 평가되므로 변수의 마지막 언급이 우선순위를 가집니다. 
include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

secret_detection:
  variables:
    SECRET_DETECTION_HISTORIC_SCAN: "true"

사전 정의된 분석기 규칙 재정의

사용자 정의하려는 특정 파이프라인 시크릿 검출 규칙이 있는 경우 해당 규칙을 재정의할 수 있습니다. 예를 들어, 특정 시크릿의 심각도를 높일 수 있습니다.

규칙을 재정의하려면:

  1. 프로젝트 루트에 .gitlab 디렉터리를 생성합니다(이미 있다면 해당 단계를 건너뜁니다).
  2. 프로젝트의 .gitlab 디렉터리에 secret-detection-ruleset.toml이라는 사용자 정의 규칙세트 파일을 생성합니다(이미 있다면 해당 단계를 건너뜁니다).
  3. 하나 이상의 ruleset.identifier 하위 섹션에서 규칙을 재정의합니다. 모든 ruleset.identifier 섹션에는 다음이 있습니다:
    • 사전 정의 룰 식별자에 대한 type 필드.
    • 규칙 이름에 대한 value 필드.
  4. ruleset 섹션의 ruleset.override 컨텍스트에서 재정의할 키를 제공합니다. 키의 모든 조합을 재정의할 수 있습니다. 유효한 키는 다음과 같습니다:
    • description
    • message
    • name
    • severity(유효한 옵션: Critical, High, Medium, Low, Unknown, Info)

다음 예제의 secret-detection-ruleset.toml 파일에서 규칙을 일치시키고 재정의합니다: 

[secrets]
  [[secrets.ruleset]]
    [secrets.ruleset.identifier]
      type = "gitleaks_rule_id"
      value = "RSA private key"
    [secrets.ruleset.override]
      description = "재정의된 설명"
      message = "재정의된 메시지"
      name = "재정의된 이름"
      severity = "Info"

미리 정의된 분석기 규칙 비활성화

특정 Pipeline Secret Detection 규칙을 활성화하고 싶지 않은 경우, 해당 규칙을 비활성화할 수 있습니다.

분석기 규칙을 비활성화하려면:

  1. 프로젝트의 루트에 .gitlab 디렉터리를 생성합니다(이미 존재하지 않은 경우).
  2. .gitlab 디렉터리에 secret-detection-ruleset.toml이라는 사용자 정의 규칙 파일을 생성합니다(이미 존재하지 않은 경우).
  3. ruleset 섹션의 컨텍스트에서 disabled 플래그를 true로 설정합니다.
  4. 하나 이상의 ruleset.identifier 하위 섹션에 비활성화할 규칙을 나열합니다. 각 ruleset.identifier 섹션에는 다음이 있습니다:
    • 미리 정의된 규칙 식별자에 대한 type 필드
    • 규칙 이름에 대한 value 필드

다음 예에서 secret-detection-ruleset.toml 파일에서 비활성화된 규칙은 type과 value가 일치하는 식별자에 secrets로 할당됩니다: 

[secrets]
  [[secrets.ruleset]]
    disable = true
    [secrets.ruleset.identifier]
      type = "gitleaks_rule_id"
      value = "RSA private key"

사용 가능한 CI/CD 변수

Pipeline Secret Detection은 사용 가능한 CI/CD 변수를 정의함으로써 사용자 정의할 수 있습니다:

CI/CD variable 기본값 설명
SECRET_DETECTION_EXCLUDED_PATHS ”” 경로를 기반으로 출력에서 취약점을 제외합니다. 경로는 쉼표로 구분된 패턴의 디렉터리입니다. 패턴은 와일드카드로(doublestar.Match 참조) 지원되는 패턴이거나 파일 또는 폴더 경로(예: doc,spec)일 수 있습니다. 상위 디렉터리도 패턴과 일치합니다. GitLab 13.3에서 도입됨
SECRET_DETECTION_HISTORIC_SCAN false 과거 Gitleaks 스캔을 활성화하는 플래그입니다.
SECRET_DETECTION_IMAGE_SUFFIX ”” 이미지 이름에 추가되는 접미사입니다. -fips로 설정하면 스캔에 FIPS-enabled 이미지가 사용됩니다. 더 자세한 내용은 FIPS-enabled 이미지 사용를 참조하십시오. GitLab 14.10에서 도입됨
SECRET_DETECTION_LOG_OPTIONS ”” 커밋 범위를 정의하는 데 사용되는 git log 옵션입니다. GitLab 15.1에서 도입됨

이전 GitLab 버전에서 다음 변수들도 사용 가능했습니다:

CI/CD variable 기본값 설명
SECRET_DETECTION_COMMIT_FROM - Gitleaks 스캔이 시작하는 커밋입니다. GitLab 13.5에서 삭제됨. SECRET_DETECTION_COMMITS로 대체되었습니다.
SECRET_DETECTION_COMMIT_TO - Gitleaks 스캔이 끝나는 커밋입니다. GitLab 13.5에서 삭제됨. SECRET_DETECTION_COMMITS로 대체되었습니다.
SECRET_DETECTION_COMMITS - Gitleaks가 스캔해야 할 커밋 디렉터리입니다. GitLab 13.5에서 도입됨 및 GitLab 15.0에서 삭제됨.

오프라인 구성

Tier: PREMIUM Offering: Self-managed

오프라인 환경은 인터넷을 통해 외부 리소스에 제한적이거나 가끔 접속할 수 있는 환경을 가집니다. Self-managed GitLab 인스턴스에 대해 이러한 환경에서 Pipeline Secret Detection은 일부 구성 변경이 필요합니다. 이 섹션의 지침은 오프라인 환경에 상세히 기술된 지침과 함께 완료해야합니다.

GitLab Runner 구성

기본적으로 러너는 로컬 복사본을 사용할 수 있는 경우에도 Docker 이미지를 GitLab 컨테이너 레지스트리에서 가져오려고 시도합니다. Docker 이미지가 항상 최신 상태를 유지하도록 기본 설정을 사용해야합니다. 그러나 네트워크 연결이 없는 경우 기본 GitLab Runner pull_policy 변수를 변경해야 합니다.

GitLab Runner CI/CD 변수 pull_policy를 if-not-present로 구성합니다.

로컬 Pipeline Secret Detection 분석기 이미지 사용

GitLab 컨테이너 레지스트리 대신 로컬 Docker 레지스트리에서 이미지를 가져오고 싶다면 로컬 Pipeline Secret Detection 분석기 이미지를 사용하십시오.

준비사항:

  • 로컬 오프라인 Docker 레지스트리로 Docker 이미지를 가져오는 것은 네트워크 보안 정책에 따라 달라집니다. 외부 리소스에 접근하거나 임시로 접속하는 수락된 프로세스를 찾기 위해 IT 직원과 상의하십시오.

  1. 기본 Pipeline Secret Detection 분석기 이미지를 registry.gitlab.com에서 로컬 Docker 컨테이너 레지스트리로 가져옵니다: 

    registry.gitlab.com/security-products/secrets:4

    Pipeline Secret Detection 분석기 이미지는 주기적으로 업데이트되므로 정기적으로 로컬 복사본을 업데이트해야합니다.

  2. CI/CD 변수 SECURE_ANALYZERS_PREFIX를 로컬 Docker 컨테이너 레지스트리로 설정합니다. 

    include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml
   
variables:
  SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

Pipeline Secret Detection 작업은 이제 인터넷 연결 없이 로컬 복사본의 Secret Detection 분석기 Docker 이미지를 사용해야합니다.

사용자 정의 SSL CA 인증서 사용

사용자 정의 Certificate Authority를 신뢰하려면 ADDITIONAL_CA_CERT_BUNDLE 변수를 신뢰하는 CA 인증서 번들로 설정하십시오. .gitlab-ci.yml 파일, 파일 변수 또는 CI/CD 변수 중 하나에서 수행할 수 있습니다.

  • .gitlab-ci.yml 파일에서 ADDITIONAL_CA_CERT_BUNDLE 값은 X.509 PEM 공개키 인증서의 텍스트 표현을 포함해야합니다.

    예: 

    variables:
  ADDITIONAL_CA_CERT_BUNDLE: |
      -----BEGIN CERTIFICATE-----
      MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
      ...
      jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
      -----END CERTIFICATE-----

  • 파일 변수를 사용하는 경우, ADDITIONAL_CA_CERT_BUNDLE 값을 인증서의 경로로 설정합니다.

  • 변수를 사용하는 경우, ADDITIONAL_CA_CERT_BUNDLE 값은 인증서의 텍스트 표현으로 설정합니다.

지원되는 언어 및 패키지 관리자

CycloneDX 소프트웨어 부자재 지원

FIPS 활성화된 이미지

기본 스캐너 이미지는 크기 및 유지 관리를 위해 기본 Alpine 이미지에서 빌드됩니다. GitLab은 FIPS를 활성화한 Red Hat UBI 이미지 버전을 제공합니다.

FIPS 활성화된 이미지를 사용하려면 다음 중 하나를 수행하십시오:

  • SECRET_DETECTION_IMAGE_SUFFIX CI/CD 변수를 -fips로 설정합니다.
  • 기본 이미지 이름에 -fips 확장자를 추가합니다.

예를 들어: 

variables:
  SECRET_DETECTION_IMAGE_SUFFIX: '-fips'

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

문제 해결

디버그 수준 로깅

문제 해결할 때 디버그 수준 로깅이 도움이 될 수 있습니다. 자세한 내용은 debug-level logging을 참조하십시오.

경고: gl-secret-detection-report.json: no matching files

이에 대한 정보는 일반적인 응용 프로그램 보안 문제 해결 섹션을 참조하십시오.

오류: Couldn't run the gitleaks command: exit status 2

파이프라인 Secret Detection 분석기는 커밋 간의 패치를 생성하여 비밀 내용을 스캔하는 데 의존합니다. 만약 Merge Request의 커밋 수가 GIT_DEPTH CI/CD 변수의 값보다 크다면 Secret Detection은 비밀을 감지하지 못합니다.

예를 들어, Merge Request을 트리거하는 파이프라인에는 60개의 커밋이 포함되어 있고 GIT_DEPTH 변수가 60보다 작게 설정된 경우, 파이프라인 Secret Detection 작업은 관련 커밋을 모두 포함하지 못했기 때문에 실패합니다. 현재 값을 확인하려면 파이프라인 구성을 참조하십시오.

이 문제를 해결하기 위해 GIT_DEPTH CI/CD 변수를 더 높은 값으로 설정하십시오. 이를 파이프라인 Secret Detection 작업에만 적용하려면 다음을 .gitlab-ci.yml 파일에 추가할 수 있습니다. 

secret_detection:
  variables:
    GIT_DEPTH: 100

오류: ERR fatal: ambiguous argument

파이프라인 Secret Detection은 리포지터리의 기본 브랜치가 작업이 트리거된 브랜치와 관련이 없는 경우 ERR fatal: ambiguous argument 오류 메시지로 실패할 수 있습니다. 자세한 내용은 이슈 !352014를 참조하십시오.

이 문제를 해결하려면 리포지터리의 기본 브랜치를 올바르게 설정하십시오. 작업을 트리거한 브랜치와 관련된 히스토리가 있는 브랜치로 설정해야 합니다.

작업 로그에서 exec /bin/sh: exec format error 메시지

GitLab 파이프라인 Secret Detection 분석기는 amd64 CPU 아키텍처에서만 지원됩니다. 이 메시지는 작업이 arm과 같은 다른 아키텍처에서 실행되고 있음을 나타냅니다.

경고

유출된 비밀에 대한 응답

비밀이 감지되면 즉시 그것을 변경해야 합니다. GitLab은 유출된 비밀의 일부 유형을 자동으로 철회하려고 합니다. 자동으로 철회되지 않는 경우 매뉴얼으로 해야합니다.

리포지터리 히스토리에서 비밀을 제거하는 것이 유출에 대한 완전한 해결책은 아닙니다. 원본 비밀은 리포지터리의 기존 포크나 복제에 그대로 남아 있습니다.

텍스트 내용에서 잠재적인 유출에 대한 경고

  • GitLab 15.11에 도입되었습니다.
  • 사용자가 정의한 접두사를 사용하여 개인 액세스 토큰을 감지하는 기능은 GitLab 16.1에서 도입되었습니다. GitLab의 Self-managed만 해당됩니다.

이슈를 작성하거나 Merge Request을 제안하거나 댓글을 작성할 때 민감한 값이 실수로 게시될 수 있습니다. 예를 들어 API 요청의 세부 정보나 인증 토큰이 포함된 환경 변수를 붙여 넣을 수 있습니다.

GitLab은 이슈 설명, Merge Request 설명, 댓글 또는 답글의 텍스트에 민감한 토큰이 포함되어 있는지 확인합니다. 토큰이 발견되면 경고 메시지가 표시됩니다. 그런 다음 게시하기 전에 메시지를 편집할 수 있습니다. 이 확인은 메시지가 서버로 보내기 전에 브라우저에서 수행됩니다. 설정할 필요가 없이 항상 활성화되어 있습니다.

귀하의 텍스트는 다음과 같은 비밀 유형에 대해 확인됩니다:

이 기능은 파이프라인 Secret Detection 스캔과 별개로 작동하며 리포지터리에서 유출된 비밀을 확인합니다. 이슈 405147에서 이 두 가지 종류의 보호를 조율하기 위한 노력이 추적됩니다.