파이프라인 비밀 검출

Tier: Free Offering: GitLab.com Status: Experimental

파이프라인 비밀 검출은 GitLab에 푸시된 후 커밋된 파일을 스캔합니다.

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

GitLab Ultimate를 사용하면, 파이프라인 비밀 검출 결과가 다음과 같이 처리됩니다:

파이프라인 비밀 검출 문서의 대화식 읽기와 실습 방법은 다음을 참조하세요:

다른 대화식 읽기와 실습 방법은 Get Started With GitLab Application Security Playlist를 참조하세요.

검출된 비밀

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는 대부분의 경우에 설정됩니다. 그러나 새 브랜치에 처음 푸시되는 경우나 병합 파이프라인의 경우에는 설정되지 않습니다. 이로 인해 파이프라인 비밀 검출은 새 브랜치에 여러 커밋이 커밋될 때를 보장할 수 없습니다.

  • 병합 요청 병합 요청에서, 파이프라인 비밀 검출은 소스 브랜치에서 이루어진 모든 커밋을 스캔합니다. 이 기능을 사용하려면, 최신 파이프라인 비밀 검출 템플릿을 사용해야 합니다. 또한, 병합 요청 파이프라인을 지원하기 때문에 파이프라인 비밀 검출의 결과는 파이프라인이 완료된 후에만 사용할 수 있습니다.

전체 히스토리 파이프라인 비밀 검출

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

파이프라인 비밀 검출을 활성화한 후에 전체 히스토리 스캔은 한 번만 실행해야 합니다. 특히, 더 큰 저장소의 경우 시간이 오래 걸릴 수 있습니다. 초기 전체 히스토리 스캔을 완료한 후에는 파이프라인의 일부로서 표준 파이프라인 비밀 검출만 사용해야 합니다.

설정

요구 사항

필수 조건:

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

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

기능 Free 및 Premium에서 Ultimate에서
Pipeline Secret Detection 스캐너 구성 가능 가능
Pipeline Secret Detection 설정 사용자 정의 가능 가능
SAST 출력 다운로드 가능 가능
게시되기 전 잠재적인 비밀 유출에 대한 경고 확인 가능 가능
병합 요청 위젯에서 새로운 발견 확인 불가능 가능
파이프라인의 보안 탭에서 식별된 비밀 확인 No 가능
취약점 관리 No 가능
보안 대시보드 접근 No 가능
Pipeline Secret Detection ruleset 사용자 정의 No 가능

분석기 활성화

Pipeline Secret Detection을 활성화하려면 다음 중 하나를 수행하십시오:

  • Auto DevOps를 활성화하십시오. 이에는 Auto Pipeline Secret Detection이 포함됩니다.

  • [.gitlab-ci.yml 파일을 수동으로 편집](#edit-the-gitlab-ciyml-file-manually)하십시오. 이 방법은 .gitlab-ci.yml` 파일이 복잡한 경우에 사용하십시오.

  • 자동으로 구성된 병합 요청을 사용하십시오(#use-an-automatically-configured-merge-request).

.gitlab-ci.yml` 파일 수동으로 편집

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

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾으십시오.
  2. 빌드 > 파이프라인 편집기를 선택하십시오.

  3. 다음을 .gitlab-ci.yml 파일의 맨 아래에 복사하여 붙여넣기하십시오: 

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

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

자동으로 구성된 병합 요청 사용

이 방법은 파이프라인 시크릿 탐지 템플릿이 .gitlab-ci.yml 파일에 포함된 병합 요청을 자동으로 준비합니다. 그런 다음 병합 요청을 통해 파이프라인 시크릿 탐지를 활성화할 수 있습니다.

참고: 이 방법은 기존의 .gitlab-ci.yml 파일이 없는 경우 또는 최소한의 구성 파일이 있는 경우에 가장 잘 작동합니다. 복잡한 GitLab 구성 파일의 경우, 성공적으로 구문 분석되지 않을 수 있으며 에러가 발생할 수 있습니다. 그 경우 수동 방법을 대신 사용하십시오.

Pipeline Secret Detection을 활성화하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾으십시오.
  2. 보안 > 보안 구성을 선택하십시오.
  3. 파이프라인 시크릿 탐지 행에서 병합 요청으로 구성을 선택하십시오.
  4. 선택 사항. 필드를 작성하십시오.
  5. 병합 요청 생성을 선택하십시오.
  6. 병합 요청을 검토하고 병합합니다.

이제 파이프라인은 파이프라인 시크릿 탐지 작업을 포함합니다.

분석기 설정 사용자 정의

파이프라인 시크릿 검색 설정은 CI/CD 변수를 통해 변경할 수 있습니다. .gitlab-ci.yml 파일의 variables 파라미터를 사용하여 변경할 수 있습니다.

경고: GitLab 보안 스캔 도구의 모든 구성은 기본 브랜치에 변경 사항을 병합하기 전에 병합 요청에서 테스트해야 합니다. 이를 하지 않으면 예기치 않은 결과가 발생할 수 있으며, 많은 수의 잘못된 긍정 결과가 발생할 수 있습니다.

새로운 패턴 추가

저장소에서 다른 유형의 시크릿을 검색하려면 사용자 정의 규칙 세트를 구성할 수 있습니다.

Pipeline Secret Detection의 모든 사용자를 대상으로 새로운 검색 규칙을 제안하려면 기본 규칙을 포함하는 파일에 대한 병합 요청을 만들어야 합니다.

클라우드나 SaaS 제품을 운영하고 있고 GitLab과 협력하여 사용자를 보다 잘 보호하고 싶다면, 유출된 자격 증명 알림을 위한 협력 프로그램에 대해 자세히 알아보세요.

시크릿 무시

일부 경우에는 시크릿을 무시하려고 할 수 있습니다. 예를 들어 예제나 테스트 스위트에 가짜 시크릿이 있는 경우입니다. 이러한 경우에는 보고 대상으로 하지 않고 시크릿을 무시하려고 합니다.

시크릿을 무시하려면 시크릿이 포함된 줄에 주석으로 gitleaks:allow를 추가하면 됩니다.

예시: 

 "A personal token for GitLab will look like glpat-JUST20LETTERSANDNUMB" #gitleaks:allow

특정 분석기 버전 고정

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

일부 경우에 특정 버전을 사용해야 할 수 있습니다. 예를 들어 나중에 릴리스에 퇴보를 피해야 하는 경우입니다.

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

태그를 다음과 같이 설정할 수 있습니다:

  • 4와 같은 주 버전: 이 경우 파이프라인은 이 주 버전 내에서 릴리스된 모든 마이너 또는 패치 업데이트를 사용합니다.
  • 4.5와 같은 마이너 버전: 이 경우 파이프라인은 이 마이너 버전 내에서 릴리스된 모든 패치 업데이트를 사용합니다.
  • 4.5.0와 같은 패치 버전: 이 경우 파이프라인은 어떠한 업데이트도 받지 않습니다.

다음 예시는 특정 마이너 버전의 분석기를 사용하는 방법을 보여줍니다: 

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

secret_detection:
  variables:
    SECRETS_ANALYZER_VERSION: "4.5"

기본 구성 확장

기본 구성을 추가 변경하여 Gitleaks extend 지원을 사용할 수 있습니다.

다음의 file 패스스루 예시에서 glpat-1234567890abcdefghij 문자열은 Pipeline Secret Detection에서 무시됩니다. 해당 GitLab 개인 액세스 토큰(PAT)은 테스트 케이스에서 사용됩니다. 이를 감지하는 것은 잘못된 긍정 결과가 될 것입니다.

secret-detection-ruleset.toml 파일은 extended-gitleaks-config.toml 파일의 구성을 정의합니다. extended-gitleaks-config.toml 파일은 사용자 정의 Gitleaks 구성을 정의합니다. allowlist 스탠자는 무시할 시크릿을 매칭시키는 정규식을 정의합니다. 

### .gitlab/secret-detection-ruleset.toml
[secrets]
  description = 'secrets custom rules configuration'

  [[secrets.passthrough]]
    type  = "file"
    target = "gitleaks.toml"
    value = "extended-gitleaks-config.toml"

### extended-gitleaks-config.toml
title = "extension of gitlab's default gitleaks config"

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

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

완전한 히스토리 파이프라인 시크릿 검색 활성화

완전한 히스토리 파이프라인 시크릿 검색을 활성화하려면 .gitlab-ci.yml 파일에서 변수 SECRET_DETECTION_HISTORIC_SCAN을 true로 설정하면 됩니다.

병합 요청 파이프라인에서 작업 실행

병합 요청 파이프라인에서 보안 스캔 도구를 사용하는 방법은 병합 요청 파이프라인에서 보안 스캔 도구 사용을 참조하세요.

사용자 정의 규칙 세트

자세한 내용: Tier: Ultimate

파이프라인 시크릿 검색에 나타나는 시크릿을 사용자 정의할 수 있습니다. 그러나 secret_detection 작업 로그에는 언제나 기본 Pipeline Secret Detection 규칙으로 검출된 시크릿의 수가 포함됩니다.

다음과 같은 사용자 정의 옵션을 따로 또는 병행하여 사용할 수 있습니다:

사용자 정의 구성 통합

기본 파이프라인 시크릿 감지 규칙을 재정의하기 위해 passthroughs를 사용할 수 있습니다. secrets 분석기에서 지원하는 다음 passthrough 유형이 있습니다:

  • raw
  • file

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

  • 인라인(raw) 값 사용: 

    [secrets]
  description = '시크릿 사용자 정의 규칙 구성'

  [[secrets.passthrough]]
    type  = "raw"
    target = "gitleaks.toml"
    value = """\
title = "gitleaks config"
### 정규식을 정규식 테이블에 추가
[[rules]]
description = "Custom Raw Rulesets 테스트"
regex = '''Custom Raw Ruleset T[est]{3}'''
"""

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

    [secrets]
  description = '시크릿 사용자 정의 규칙 구성'

  [[secrets.passthrough]]
    type  = "file"
    target = "gitleaks.toml"
    value = "config/gitleaks.toml"

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

원격 구성 파일 지정

프로젝트는 CI/CD 변수를 사용하여 현재 리포지토리 외부에서 규칙셋 구성을 지정할 수 있습니다.

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

<AUTH_USER>:<AUTH_PASSWORD>@<PROJECT_PATH>@<GIT_SHA>

참고: 프로젝트 내의 로컬 .gitlab/secret-detection-ruleset.toml 파일이 SECRET_DETECTION_RULESET_GIT_REFERENCE보다 우선합니다.

다음 예제는 프로젝트에 파이프라인 시크릿 감지 템플릿을 포함하고 별도 프로젝트 구성을 참조하기 위해 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 파일의 예에서: - 파이프라인 시크릿 감지 템플릿이 포함됩니다. - 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 파일에서 규칙은 식별자의 type 및 value와 일치시켜 다음과 같이 재정의됩니다: 

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

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

특정 파이프라인 비밀 감지 규칙 중 원하지 않는 규칙이 있다면, 해당 규칙을 비활성화할 수 있습니다.

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

  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 변수

파이프라인 비밀 감지는 사용 가능한 CI/CD 변수를 정의하여 사용자 정의할 수 있습니다:

CI/CD 변수 기본값 설명
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 변수 기본값 설명
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

오프라인 환경은 인터넷을 통해 외부 리소스에 제한적이거나 간헐적으로 액세스할 수 있는 환경을 가지고 있습니다. 이러한 환경에서 자체 관리 GitLab 인스턴스의 경우, 파이프라인 비밀 감지에는 일부 구성 변경이 필요합니다. 이 섹션의 지침은 오프라인 환경에서 상세히 설명된 지침과 함께 완료해야 합니다.

GitLab Runner 구성

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

GitLab Runner의 CI/CD 변수 pull_policy를 if-not-present로 구성하세요.

로컬 파이프라인 시크릿 검색기 이미지 사용

로컬 파이프라인 시크릿 검색기 이미지를 사용하면 GitLab 컨테이너 레지스트리가 아닌 로컬 Docker 레지스트리에서 이미지를 가져올 수 있습니다.

필수 사항:

  • 오프라인 로컬 Docker 레지스트리로 Docker 이미지를 가져오려면 네트워크 보안 정책에 따라 달립니다. 외부 자료에 엑세스하는 허용되고 승인된 프로세스를 찾으려면 IT 직원과 상의하세요.

  1. 기본 파이프라인 시크릿 검색기 이미지를 registry.gitlab.com에서 로컬 Docker 컨테이너 레지스트리로 가져오기: 

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

    파이프라인 시크릿 검색기 이미지는 주기적으로 업데이트되므로 로컬 사본을 주기적으로 업데이트해야 합니다.

  2. CI/CD 변수 SECURE_ANALYZERS_PREFIX를 로컬 Docker 컨테이너 레지스트리로 설정하세요. 

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

variables:
  SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"

파이프라인 시크릿 검색 작업은 이제 인터넷 액세스 없이 시크릿 검색기 Docker 이미지의 로컬 사본을 사용해야 합니다.

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

사용자 정의 인증 기관을 신뢰하려면 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 Software Bill of Materials 지원

FIPS 활성화된 이미지

기본 스캐너 이미지는 크기와 유지 관리를 위해 기본 알파인 이미지를 기반으로 구축됩니다. GitLab은 FIPS를 지원하는 Red Hat UBI 버전의 이미지를 제공합니다.

FIPS 활성화된 이미지를 사용하려면:

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

예: 

variables:
  SECRET_DETECTION_IMAGE_SUFFIX: '-fips'

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

문제 해결

디버그 수준 로깅

문제 해결 시 디버그 수준 로깅이 도움이 될 수 있습니다. 자세한 내용은 디버그 수준 로깅을 참조하세요.

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

이에 대한 정보는 일반 어플리케이션 보안 문제 해결 섹션을 참조하세요.

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

파이프라인 시크릿 검색기는 커밋 간 패치를 생성하여 시크릿을 검색하는 데 의존합니다. 만약 병합 요청의 커밋 수가 GIT_DEPTH CI/CD 변수 값보다 크다면 시크릿 검색이 실패할 수 있습니다.

예를 들어, 병합 요청에 60개의 커밋이 포함된 파이프라인이 있고 GIT_DEPTH 변수가 60보다 작게 설정된 경우 파이프라인 시크릿 검색 작업이 실패합니다. 현재 값을 확인하려면 파이프라인 설정을 참조하세요.

오류의 원인으로 확인하려면 디버그 수준 로깅을 활성화한 후 파이프라인을 다시 실행하세요. 로그는 다음 예와 유사해야 합니다. “object not found” 텍스트는 이 오류의 증상입니다. 

ERRO[2020-11-18T18:05:52Z] object not found
[ERRO] [secrets] [2020-11-18T18:05:52Z] ▶ Couldn't run the gitleaks command: exit status 2
[ERRO] [secrets] [2020-11-18T18:05:52Z] ▶ Gitleaks analysis failed: exit status 2

이 문제를 해결하려면 GIT_DEPTH CI/CD 변수 값을 더 큰 값으로 설정하세요. 이를 파이프라인 시크릿 검색 작업에만 적용하려면 다음을 .gitlab-ci.yml 파일에 추가할 수 있습니다: 

secret_detection:
  variables:
    GIT_DEPTH: 100

오류: ERR fatal: ambiguous argument

Pipeline Secret Detection은 작업이 트리거된 브랜치와 관련이 없는 리포지토리의 기본 브랜치 때문에 ERR fatal: ambiguous argument 오류가 발생할 수 있습니다. 자세한 내용은 이슈 !352014를 참조하세요.

이 문제를 해결하려면 리포지토리의 기본 브랜치를 올바르게 설정해야 합니다. secret-detection 작업을 실행하는 브랜치와 관련된 이력이 있는 브랜치로 설정해야 합니다.

작업 로그에 나타난 exec /bin/sh: exec format error 메시지

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

경고

누출된 비밀번호에 응답

비밀번호가 감지되면 즉시 해당 비밀번호를 변경해야 합니다. GitLab은 누출된 일부 유형의 비밀번호를 자동으로 폐기하려고 합니다. 자동으로 폐기되지 않는 비밀번호에 대해서는 수동으로 폐기해야 합니다.

리포지토리 이력에서 비밀번호를 삭제해도 누출된 비밀번호 문제는 완전히 해결되지 않습니다. 원래의 비밀번호는 리포지토리의 기존 포크나 클론에 계속 남아 있습니다.

텍스트 콘텐츠에서 잠재적인 누출에 대한 경고

  • GitLab 15.11에 도입되었습니다.
  • 사용자 설정형 접두어를 사용하는 개인 액세스 토큰의 감지가 GitLab 16.1에 도입되었습니다. GitLab Self-Managed 전용입니다.

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

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

다음과 같은 비밀번호 유형에 대해 텍스트가 확인됩니다.

이 기능은 리포지토리의 누출된 비밀번호를 확인하는 Pipeline Secret Detection 스캔과 별개입니다. 이 두 가지 보호 유형을 조화시키기 위한 노력은 이슈 405147에서 추적됩니다.