감지된 비밀
커버리지
전체 히스토리 파이프라인 비밀 감지
고급 취약점 추적
- 지원되지 않는 워크플로우
출력
구성
FIPS 활성화된 이미지
문제 해결
- 디버그 수준 로깅
경고
- 유출된 시크릿 대응

파이프라인 비밀 감지

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

파이프라인 비밀 감지는 Git 저장소에 커밋되고 GitLab에 푸시된 후 파일을 스캔합니다.

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

GitLab Ultimate를 사용하면 파이프라인 비밀 감지 결과도 처리되어 다음을 수행할 수 있습니다.

병합 요청 위젯, 파이프라인 보안 보고서, 그리고 취약점 보고서 UI에서 결과 확인
승인 워크플로에 사용
보안 대시보드에서 검토
공개 저장소의 유출에 대응하기 위한 자동 응답
보안 정책을 사용하여 프로젝트 간 일관된 비밀 감지 규칙 강제

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

다른 대화식 읽기와 실습 방법은 GitLab 응용 보안 재생 목록으로 시작하세요.

감지된 비밀

GitLab은 파이프라인 비밀 감지에서 사용하는 감지 규칙을 유지합니다. 기본 규칙 세트에는 100여 가지 이상의 패턴이 포함되어 있습니다.

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

더 신뢰할 수 있고 높은 확신을 제공하기 위해 파이프라인 비밀 감지는 URL과 같은 특정 문맥에서만 비밀이나 다른 구조화되지 않은 비밀을 찾습니다.

스캔된 파일에서 비밀을 제거해도 감지된 비밀은 “아직도 감지됨”이라는 취약점 보고서에 남습니다. 이는 비밀이 여전히 Git 저장소의 히스토리에 남아 있기 때문입니다. 감지된 비밀을 해결하려면 정보 유출을 해소한 다음 취약점을 진단하세요.

커버리지

파이프라인 비밀 감지는 상황에 따라 코드의 다양한 측면을 스캔합니다. “기본 브랜치”를 제외한 모든 방법에서 파이프라인 비밀 감지는 워킹 트리가 아닌 커밋을 스캔합니다. 예를 들어, 파이프라인 비밀 감지는 비밀이 한 커밋에 추가되고 나중에 다른 커밋에서 제거된 경우를 감지할 수 있습니다.

히스토리 스캔
SECRET_DETECTION_HISTORIC_SCAN 변수가 설정되어 있으면 모든 브랜치의 내용이 스캔됩니다. Git 저장소의 내용을 스캔하기 전에 파이프라인 비밀 감지는 모든 브랜치의 내용을 가져 오기 위해 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 저장소의 전체 히스토리를 스캔할 수 있습니다.

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

고급 취약점 추적

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

GitLab 17.0에 도입.

개발자가 식별된 비밀이 포함된 파일을 수정할 때 이러한 비밀의 위치가 변경될 가능성이 큽니다. 파이프라인 비밀 감지는 이미 이러한 비밀을 취약점으로 식별했을 수 있습니다. 이 취약점은 특정 비밀과 연결되어 있어 쉽게 식별하고 조치할 수 있습니다. 그러나 감지된 비밀이 이동함에 따라 정확하게 추적되지 않으면 취약점 관리가 어려워져 중복된 취약점 보고서가 발생할 수 있습니다.

파이프라인 비밀 감지는 고급 취약점 추적 알고리즘을 사용하여 비밀이 동일한 파일 내에서 리팩터링되거나 관련 없는 변경으로 인해 이동 될 때 더 정확하게 식별합니다.

자세한 정보는 비밀 프로젝트 https://gitlab.com/gitlab-org/security-products/post-analyzers/tracking-calculator를 참조하세요. 이 프로젝트의 내용은 GitLab 팀 멤버에게만 사용할 수 있습니다.

지원되지 않는 워크플로우

알고리즘은 기존 발견이 추적 서명이 없거나 새로 발견된 항목과 동일한 위치를 공유하지 않는 워크플로우를 지원하지 않습니다.
암호화 키와 같은 규칙 유형의 경우, 파이프라인 비밀 검출은 비밀의 전체 값이 아닌 접두사를 매칭하여 유출을 식별합니다. 이 시나리오에서 알고리즘은 동일한 규칙 유형의 다양한 비밀을 파일에서 하나의 발견으로 통합하고 각각을 별도의 발견으로 취급하는 대신 동일한 비밀을 하나의 발견으로 처리합니다. 예를 들어, SSH 개인 키 규칙 유형은 값의 -----BEGIN OPENSSH PRIVATE KEY----- 접두사만 매칭하여 SSH 개인 키의 존재를 확인합니다. 파일 내에 두 개의 서로 다른 SSH 개인 키가 있는 경우 알고리즘은 두 값 모두를 동일하게 간주하고 둘 중 하나의 발견 대신 둘 다중 하나의 발견으로 보고합니다.
알고리즘의 범위는 파일 단위로 제한되어 있으며, 두 개의 다른 파일에 나타나는 동일한 비밀은 두 개의 별도 발견으로 처리됩니다.

출력

파이프라인 비밀 검출은 작업 결과로 파일 gl-secret-detection-report.json을 출력합니다. 이 파일에는 감지된 비밀이 포함되어 있습니다. GitLab 외부에서 처리하려면 파일을 다운로드할 수 있습니다.

더 많은 정보는 아래에서 확인하세요:

구성

요구 사항

전제 조건:

docker 또는 kubernetes 실행자가 있는 Linux 기반 GitLab Runner가 필요합니다. GitLab.com의 공유 러너를 사용하는 경우, 기본적으로 이러한 실행자가 활성화됩니다.
- Windows 러너는 지원되지 않습니다.
- amd64 이외의 CPU 아키텍처는 지원되지 않습니다.
GitLab CI/CD 구성(.gitlab-ci.yml)에 test 단계를 포함해야 합니다.

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

기능	무료 및 프리미엄	얼티메이트
분석기 활성화	가능	가능
분석기 설정 사용자 정의	가능	가능
출력 다운로드	가능	가능
병합 요청 위젯에서 새로운 발견 보기	불가능	가능
파이프라인의 보안 탭에서 식별된 비밀 보기	불가능	가능
취약점 관리	불가능	가능
보안 대시보드에 액세스	불가능	가능
분석기 규칙 세트 사용자 정의	불가능	가능
보안 정책 활성화	불가능	가능

분석기 활성화

파이프라인 비밀 검출을 활성화하려면 다음 중 하나를 수행하세요:

Auto Secret Detection을 포함한 Auto DevOps를 활성화합니다.
.gitlab-ci.yml 파일을 수동으로 편집합니다. .gitlab-ci.yml 파일이 복잡한 경우에는 이 방법을 사용하세요.
자동으로 구성된 병합 요청 사용합니다.

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

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

왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
Build > 파이프라인 편집기를 선택합니다.
다음을 .gitlab-ci.yml 파일의 맨 아래에 복사하여 붙여넣습니다.:
```
include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml
```
검증 탭을 선택한 다음 파이프라인 검증을 선택합니다. 메시지 시뮬레이션이 성공적으로 완료되었습니다는 파일이 유효하다는 것을 나타냅니다.
편집 탭을 선택합니다.
옵션. 커밋 메시지 텍스트 상자에서 커밋 메시지를 사용자 정의합니다.
브랜치 텍스트 상자에 기본 브랜치의 이름을 입력합니다.
변경 사항 커밋을 선택합니다.

이제 파이프라인에 파이프라인 비밀 검출 작업이 포함됩니다.

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

feature 플래그에 의해 기본적으로 활성화되어 있는 필드에서 GitLab 13.11에서 소개되었습니다.
GitLab 14.1에서 feature flag가 제거되었습니다.

이 방법은 파이프라인 비밀 검출 템플릿이 .gitlab-ci.yml 파일에 포함된 병합 요청을 자동으로 준비합니다. 그런 다음 병합 요청을 병합하여 파이프라인 비밀 검출을 활성화합니다.

참고: 이 방법은 기존 .gitlab-ci.yml 파일이 없거나 최소한의 구성 파일을 사용하는 경우가 가장 적합합니다. 복잡한 GitLab 구성 파일을 사용하는 경우 이 방법을 사용하면 파일이 정상적으로 구문 분석되지 않을 수 있으며 오류가 발생할 수 있습니다. 이 경우 수동 방법을 사용하세요.

파이프라인 비밀 검출을 활성화하려면:

왼쪽 사이드 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
보안 > 보안 구성을 선택합니다.
파이프라인 비밀 검출 행에서 병합 요청으로 구성을 선택합니다.
옵션. 필드를 완료합니다.
병합 요청 생성을 선택합니다.
병합 요청을 검토하고 병합합니다.

이제 파이프라인에 파이프라인 비밀 검출 작업이 포함됩니다.

분석기 설정 사용자 정의

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

경고: GitLab 보안 스캔 도구의 모든 구성은 기본 브랜치로 변경하기 전에 병합 요청에서 테스트해야 합니다. 그렇지 않으면 예상치 못한 결과가 발생할 수 있으며, 이는 대부분의 거짓 양성을 유발할 수 있습니다.

새로운 패턴 추가

귀하의 저장소에서 다른 유형의 시크릿을 검색하려면 분석기 규칙 집합을 사용자 정의할 수 있습니다.

파이프라인 시크릿 감지의 모든 사용자에 대한 새로운 검출 규칙을 제안하려면 기본 규칙을 포함하는 파일에 대한 병합 요청을 생성하세요.

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

특정 분석기 버전에 고정

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"

전체 히스토리 스캔 활성화

전체 히스토리 스캔을 활성화하려면 .gitlab-ci.yml 파일에서 변수 SECRET_DETECTION_HISTORIC_SCAN을 true로 설정하세요.

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

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

분석기 작업 재정의

작업 정의를 재정의하려면(예: variables 또는 dependencies와 같은 속성 변경),secret_detection 작업과 동일한 이름의 작업을 선언하여 재정의하세요. 새 작업을 템플릿 포함 후에 배치하고 그 하위에 추가 키를 지정하세요.

다음 예제에서:

Jobs/Secret-Detection CI 템플릿이 포함됩니다.
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"

분석기 규칙 집합 사용자 정의

Tier: Ultimate

GitLab 13.5에서 도입
GitLab 14.6에서 file 및 raw의 추가 전달 유형을 포함하여 확장되었습니다.
GitLab 14.8에서 규칙 재정의 지원이 활성화되었습니다.
GitLab 17.2에서 통과 체인을 지원하고 git 및 url의 추가 전달 유형을 포함하여 활성화되었습니다.

파이프라인 시크릿 감지의 동작을 규칙 집합 구성 파일 생성으로 사용자 정의할 수 있습니다. 사용자 정의를 통해 기본 규칙 집합을 수정, 교체 또는 확장할 수 있습니다.

다양한 종류의 사용자 정의가 가능합니다:

기본 규칙 집합에 정의된 규칙 동작 수정. 이는 다음을 포함합니다:
파스스루를 사용하여 기본 규칙 집합을 사용자 지정 규칙 집합으로 교체. 이는 다음을 포함합니다:
파스스루를 사용하여 기본 규칙 집합의 동작을 확장. 이는 다음을 포함합니다:
- 로컬 규칙 집합에서 구성 사용.
- 원격 규칙 집합에서 구성 사용.
Gitleaks 원본 기능을 사용하여 시크릿 및 경로 무시. 이는 다음을 포함합니다:
- Gitleaks' [allowlist] 지시문을 사용하여 패턴 및 경로 무시.
- gitleaks:allow 주석을 사용하여 인라인으로 시크릿 무시합니다.

규칙 집합 구성 파일 생성

규칙 집합 구성 파일을 생성하려면:

프로젝트의 루트에 .gitlab 디렉터리를 생성하십시오(이미 있는 경우 제외).
.gitlab 디렉터리에 secret-detection-ruleset.toml이라는 파일을 생성하십시오.

기본 규칙세트 수정

규칙을 수정하여 기존 워크플로우나 도구에 파이프라인 시크릿 감지를 적응시킬 수 있습니다. 예를 들어 감지된 시크릿의 심각도를 재정의하거나 특정 규칙을 전혀 감지하지 않도록 설정할 수 있습니다.

리모트(원격) 규칙세트로 규칙을 수정할 수 있는 기능은 GitLab 16.0부터 활성화되었습니다.

규칙을 비활성화하려면 다음을 수행할 수 있습니다:

이미 존재하지 않는 경우 규칙 세트 구성 파일을 생성하십시오.
ruleset 섹션의 맥락에서 disabled 플래그를 true로 설정하십시오.
하나 이상의 ruleset.identifier 하위 섹션에서 비활성화할 규칙을 나열하십시오. 각 ruleset.identifier 섹션에는 다음이 포함되어 있습니다:
- 미리 정의된 규칙 식별자에 대한 type 필드
- 규칙 이름에 대한 value 필드

다음 예에서 secret-detection-ruleset.toml 파일에서 비활성화된 규칙은 식별자의 type 및 value와 일치합니다:

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

규칙을 재정의하려면 다음을 수행할 수 있습니다:

이미 존재하지 않는 경우 규칙 세트 구성 파일을 생성하십시오.
하나 이상의 ruleset.identifier 하위 섹션에서 재정의할 규칙을 나열하십시오. 각 ruleset.identifier 섹션에는 다음이 포함되어 있습니다:
- 미리 정의된 규칙 식별자에 대한 type 필드
- 규칙 이름에 대한 value 필드
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 = "OVERRIDDEN description"
      message     = "OVERRIDDEN message"
      name        = "OVERRIDDEN name"
      severity    = "Info"

리모트 규칙세트를 사용하면 여러 프로젝트에 걸쳐 규칙을 수정할 수 있습니다.

미리 정의된 규칙을 리모트 규칙세트로 수정하려면 SECRET_DETECTION_RULESET_GIT_REFERENCE CI/CD 변수를 사용할 수 있습니다.

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

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

파이프라인 시크릿 감지는 리모트 규칙세트가 저장된 CI 변수가 참조하는 저장소의 .gitlab/secret-detection-ruleset.toml 파일에 구성이 정의되었다고 가정합니다. 해당 파일이 없는 경우, 하나를 생성하고 위에 기술된 재정의 또는 비활성화 단계를 따르십시오.

참고: 프로젝트의 로컬 .gitlab/secret-detection-ruleset.toml 파일이 SECURE_ENABLE_LOCAL_CONFIGURATION이 기본적으로 true로 설정되어 있기 때문에 SECRET_DETECTION_RULESET_GIT_REFERENCE보다 우선합니다. SECURE_ENABLE_LOCAL_CONFIGURATION를 false로 설정하면 로컬 파일이 무시되고 기본 구성 또는 (설정된 경우) SECRET_DETECTION_RULESET_GIT_REFERENCE가 사용됩니다.

SECRET_DETECTION_RULESET_GIT_REFERENCE 변수는 URI, 선택적 인증 및 선택적 Git SHA를 지정하는 Git URL과 유사한 형식을 사용합니다. 이 변수는 다음 형식을 사용합니다:

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

인증이 필요한 비공개 프로젝트에 구성 파일이 저장된 경우, 그룹 액세스 토큰을 CI 변수에 안전하게 저장하여 원격 규칙세트를로드할 수 있습니다.

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

variables:
  SECRET_DETECTION_RULESET_GIT_REFERENCE: "group_2504721_bot_7c9311ffb83f2850e794d478ccee36f5:$GROUP_ACCESS_TOKEN@gitlab.com/example-group/remote-ruleset-project"

그룹 액세스 토큰은 read_repository 스코프 및 최소한의 Reporter 역할이 있어야 합니다. 자세한 내용은 저장소 권한을 참조하십시오.

그룹 액세스 토큰 사용 설명을 참조하여 그룹 액세스 토큰과 관련된 사용자 이름을 찾는 방법을 알아보세요.

기본 규칙 집합 대체

여러 사용자 정의를 사용하여 기본 규칙 집합 설정을 대체할 수 있습니다. 이러한 사용자 정의는 통과를 사용하여 단일 구성으로 결합할 수 있습니다.

통과를 사용하여 다음을 할 수 있습니다:

단일 구성에 최대 20번의 통과를 연결하여 사전 정의된 규칙을 대체하거나 확장합니다.
통과 내에 환경 변수 포함시키기
통과 평가 시간 제한 설정
각 정의된 통과에 사용된 TOML 구문을 유효성 검사하기

내장 규칙 집합으로

기본 규칙 집합을 아래의 내용과 같이 제공된 구성으로 대체할 수 있습니다.

이를 위해 저장소에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 다음을 추가하고, [[rules]] 아래 정의된 규칙을 적절하게 조정합니다.

[secrets]
  [[secrets.passthrough]]
    type   = "raw"
    target = "gitleaks.toml"
    value  = """
title = "replace default ruleset with a raw passthrough"

[[rules]]
description = "Test for Raw Custom Rulesets"
regex = '''Custom Raw Ruleset T[est]{3}'''
"""

위의 예제는 기본 규칙 집합을 적용하여 정의된 정규식을 확인하는 규칙으로 대체합니다 - Custom Raw Ruleset T 다음에 e, s, 또는 t 문자 중 하나가 있는 3자리의 접미어.

사용할 통과 구문에 대한 자세한 내용은 스키마를 참조하십시오.

로컬 규칙 집합으로

기본 규칙 집합을 현재 저장소에 커밋된 다른 파일로 대체할 수 있습니다.

이를 위해 저장소에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 다음을 추가하고, value를 적절하게 조정하여 로컬 규칙 집합 구성 파일의 경로를 지정합니다.

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

이렇게 하면 기본 규칙 집합이 config/gitleaks.toml 파일에 정의된 구성으로 대체됩니다.

사용할 통과 구문에 대한 자세한 내용은 스키마를 참조하십시오.

원격 규칙 집합으로

git 및 url 통과를 사용하여 원격 Git 저장소나 온라인으로 저장된 파일에 정의된 구성으로 기본 규칙 집합을 대체할 수 있습니다.

원격 규칙 집합은 여러 프로젝트에서 사용할 수 있습니다. 예를 들어 특정 네임스페이스의 여러 프로젝트에 동일한 규칙 집합을 적용하려는 경우 해당 원격 규칙 집합을로드하여 여러 프로젝트에서 사용할 수 있습니다. 이는 규칙 집합을 중앙에서 관리하고 수정 권한이 있는 사용자만 수정할 수 있도록 합니다.

git 통과를 사용하려면 다음을 저장소에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 추가하고, value를 해당 Git 저장소 주소로 조정하십시오.

# https://gitlab.com/user_group/basic_repository 내부의 .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "git"
    ref    = "main"
    subdir = "config"
    value  = "https://gitlab.com/user_group/central_repository_with_shared_ruleset"

이 구성에서 분석기는 user_group/basic_repository 이외의 프로젝트에서도 동일한 구성을 포함할 수 있습니다.

대조적으로, url 통과를 사용하여 원격 규칙 집합 구성으로 기본 규칙 집합을 대체할 수 있습니다.

url 통과를 사용하려면 다음을 저장소에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 추가하고, value를 원격 파일의 주소로 조정하십시오.

# https://gitlab.com/user_group/basic_repository 내부의 .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "url"
    target = "gitleaks.toml"
    value  = "https://example.com/gitleaks.toml"

이 구성에서 분석기는 지정된 주소에 저장된 gitleaks.toml 파일로부터 규칙 집합 구성을 로드합니다.

사용할 통과 구문에 대한 자세한 내용은 스키마를 참조하십시오.

비공개 원격 규칙 집합으로

규칙 집합 구성이 비공개 저장소에 저장된 경우 해당 저장소에 액세스하기 위한 자격 증명을 통과의 auth 설정을 사용하여 제공해야 합니다.

참고: auth 설정은 git 통과와 함께만 작동합니다.

비공개 저장소에 저장된 원격 규칙 집합을 사용하려면 다음을 저장소에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 추가하고, 이에 적절한 자격 증명을 사용하여 auth를 업데이트하십시오.

[secrets]
  [[secrets.passthrough]]
    type   = "git"
    ref    = "main"
    auth   = "USERNAME:PASSWORD" # USERNAME 및 PASSWORD를 적절한 값으로 교체
    subdir = "config"
    value  = "https://gitlab.com/user_group/central_repository_with_shared_ruleset"

경고: 이 기능을 사용할 때 자격 증명이 노출되지 않도록 주의하십시오. 위험을 최소화하기 위해 환경 변수를 사용하는 방법에 대한 예제는 이 섹션을 확인하십시오.

사용할 통과 구문에 대한 자세한 내용은 스키마를 참조하십시오.

기본 규칙 집합 확장

원하는 경우 기본 규칙 집합 구성을 추가적인 규칙으로 확장할 수도 있습니다. 이 작업은 GitLab에서 유지하는 고신뢰 사전 정의된 규칙을 여전히 활용하고 싶지만 해당 프로젝트 및 이름공간에서 사용될 수 있는 비밀 유형에 대한 규칙을 추가하고 싶을 때 유용할 수 있습니다.

로컬 규칙 집합을 사용하는 경우

file을 사용하여 기본 규칙 집합을 확장하여 추가 규칙을 추가할 수 있습니다.

동일한 리포지토리에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 다음을 추가하고 확장 구성 파일의 경로를 가리키도록 value를 조정합니다.

# .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "file"
    target = "gitleaks.toml"
    value  = "extended-gitleaks-config.toml"

extended-gitleaks-config.toml에 저장된 확장된 구성은 CI/CD 파이프라인에서 분석기에 의해 사용되는 구성에 포함됩니다.

아래 예시에서는 여러 개의 정규 표현식을 정의하는 [[rules]] 섹션을 추가합니다.

# extended-gitleaks-config.toml
[extend]
# 기본 패키지화된 규칙 집합 확장, 참고: 경로를 변경하지 마십시오.
path = "/gitleaks.toml"

[[rules]]
  description = "예시 서비스 API 키"
  regex = '''example_api_key'''

[[rules]]
  description = "예시 서비스 API 시크릿"
  regex = '''example_api_secret'''

이 규칙 집합 구성으로 분석기는 이 두 정의된 정규 표현식 패턴과 일치하는 문자열을 감지합니다.

사용할 수 있는 패스스루 구문에 대한 자세한 내용은 스키마를 참조하세요.

원격 규칙 집합을 사용하는 경우

기본 규칙 집합을 원격 규칙 집합으로 대체할 수 있는 방식과 유사하게, 원격 Git 리포지토리에 저장된 또는 리포지토리 외부에 저장된 파일에 구성을 추가하여 기본 규칙 집합을 확장할 수도 있습니다.

이 작업은 이전에 설명된 git 또는 url 패스스루 중 하나를 사용하여 수행할 수 있습니다.

git 패스스루를 사용하려면 동일한 리포지토리에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 다음을 추가하고 확장된 구성 파일의 경로를 가리키도록 value, ref, subdir를 조정합니다.

# https://gitlab.com/user_group/basic_repository에 있는 .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "git"
    ref    = "main"
    subdir = "config"
    value  = "https://gitlab.com/user_group/central_repository_with_shared_ruleset"

파이프라인 시크릿 검출은 원격 규칙 집합 구성 파일이 main 브랜치의 config 디렉토리에 저장된 gitleaks.toml 파일로 호출된다고 가정합니다.

기본 규칙 집합을 확장하려면, 위의 예와 유사한 [extend] 지시문을 사용해야 합니다.

# https://gitlab.com/user_group/central_repository_with_shared_ruleset/-/raw/main/config/gitleaks.toml
[extend]
# 기본 패키지화된 규칙 집합 확장, 참고: 경로를 변경하지 마십시오.
path = "/gitleaks.toml"

[[rules]]
  description = "예시 서비스 API 키"
  regex = '''example_api_key'''

[[rules]]
  description = "예시 서비스 API 시크릿"
  regex = '''example_api_secret'''

url 패스스루를 사용하려면 동일한 리포지토리에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 다음을 추가하고 확장된 구성 파일의 경로를 가리키도록 value를 조정합니다.

# https://gitlab.com/user_group/basic_repository에 있는 .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "url"
    target = "gitleaks.toml"
    value  = "https://example.com/gitleaks.toml"

사용할 수 있는 패스스루 구문에 대한 자세한 내용은 스키마를 참조하세요.

Patron 및 경로 무시

파이프라인 시크릿 검출에서 특정 패턴이나 경로를 무시해야 하는 상황이 발생할 수 있습니다. 예를 들어, 테스트 스위트에서 사용될 가짜 비밀을 포함하고 있는 파일이 있을 수 있습니다.

이러한 경우, Gitleaks’ 원시 [allowlist] 지시문을 활용하여 특정 패턴이나 경로를 무시할 수 있습니다.

참고: 이 기능은 로컬 또는 원격 규칙 집합 구성 파일을 사용하더라도 작동합니다. 아래 예시는 file 패스스루를 사용한 로컬 규칙 집합을 활용합니다.

패턴을 무시하려면, 동일한 리포지토리에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 다음을 추가하고 확장 구성 파일의 경로를 가리키도록 value를 조정합니다.

# .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "file"
    target = "gitleaks.toml"
    value  = "extended-gitleaks-config.toml"

extended-gitleaks-config.toml에 저장된 확장된 구성은 사용되는 분석기 구성에 포함됩니다.

아래 예시에서는 무시해야 할 비밀과 일치하는 정규 표현식을 정의하는 [allowlist] 지시문을 추가합니다.

# extended-gitleaks-config.toml
[extend]
# 기본 패키지화된 규칙 집합 확장, 참고: 경로를 변경하지 마십시오.
path = "/gitleaks.toml"

[allowlist]
  description = "검출에서 무시할 패턴 목록"
  regexTarget = "match"
  regexes = [
    '''glpat-[0-9a-zA-Z_\\-]{20}'''
  ]

이는 20자의 숫자와 문자로 된 접미사를 가진 glpat-와 일치하는 문자열을 무시합니다.

비슷하게, 스캔되지 않거나 제외되어야 하는 특정 경로를 정의할 수 있습니다. 아래 예시에서는 [allowlist] 지시문 아래에서 무시할 경로의 배열을 정의합니다. 경로는 정규 표현식이거나 특정 파일 경로일 수 있습니다.

# extended-gitleaks-config.toml
[extend]
# 기본 패키지화된 규칙 집합 확장, 참고: 경로를 변경하지 마십시오.
path = "/gitleaks.toml"

[allowlist]
  description = "검출에서 무시할 패턴 목록"
  paths = [
    '''/gitleaks.toml''',
    '''(.*?)(jpg|gif|doc|pdf|bin|svg|socket)'''
  ]

이는 /gitleaks.toml 파일이나 지정된 확장 중 하나를 가진 파일의 비밀을 무시합니다.

사용할 수 있는 패스스루 구문에 대한 자세한 내용은 스키마를 참조하세요.

비밀번호 무시

일부 상황에서는 비밀번호를 인라인으로 무시하고 싶을 수 있습니다. 예를 들어, 예제나 테스트 스위트에 가짜 비밀번호가 있는 경우입니다. 이러한 경우에는 취약점으로 보고되지 않도록 비밀번호를 무시하고 싶을 것입니다.

비밀번호를 무시하려면 비밀번호가 포함된 줄에 주석으로 gitleaks:allow를 추가하십시오.

예시:

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

복잡한 문자열 감지

기본 규칙 집합은 거짓 양성률이 낮은 구조화된 문자열을 감지하기 위한 패턴을 제공합니다. 그러나 비밀번호와 같은 더 복잡한 문자열을 감지하려면 Gitleaks는 전방탐색이나 후방탐색을 지원하지 않기 때문에, 믿을 수 있고 일반적인 규칙으로 구조화되지 않은 문자열을 감지할 수 없습니다.

모든 복잡한 문자열을 감지할 수는 없지만 특정 사용 사례를 충족하기 위해 규칙 집합을 확장할 수 있습니다.

예를 들어, 이 규칙은 Gitleaks 기본 규칙 집합의 generic-api-key 규칙을 수정합니다:

(?i)(?:pwd|passwd|password)(?:[0-9a-z\-_\t .]{0,20})(?:[\s|']|[\s|"]){0,3}(?:=|>|=:|:{1,3}=|\|\|:|<=|=>|:|\?=)(?:'|\"|\s|=|\x60){0,5}([0-9a-z\-_.=\S_]{3,50})(?:['|\"|\n|\r|\s|\x60|;]|$)

이 정규 표현식은 다음을 일치시킵니다:

대소문자를 구분하지 않는 pwd, passwd, password로 시작하는 식별자. 이를 다른 변형으로 secret 또는 key로 조정할 수 있습니다.
식별자를 따르는 접미사. 접미사는 숫자, 문자 및 기호의 조합으로, 길이가 0에서 23 문자입니다.
=, :=, :, 또는 =>와 같은 일반적으로 사용되는 할당 연산자들.
비밀번호 접두어는 주로 비밀번호를 감지하는 데 도움이 되는 경계로 사용됩니다.
숫자, 문자 및 기호의 문자열로, 길이가 3에서 50 문자입니다. 이것이 비밀번호 자체입니다. 더 긴 문자열을 예상하는 경우 길이를 조정할 수 있습니다.
비밀번호 접미어는 일반적으로 사용되는 종료 부분과 일치합니다. 이것은 틱, 줄 바꿈 및 새 줄과 같은 일반적인 종료를 일치시킵니다.

이 정규 표현식으로 일치하는 예시 문자열은 다음과 같습니다:

pwd = password1234
passwd = 'p@ssW0rd1234'
password = thisismyverylongpassword
password => mypassword
password := mypassword
password: password1234
"password" = "p%ssward1234"
'password': 'p@ssW0rd1234'

이 정규 표현식을 사용하려면 이 페이지에 문서화된 방법 중 하나를 사용하여 규칙 집합을 확장하십시오.

예를 들어, 기본 규칙 집합을 로컬 규칙 집합으로 확장하고 싶다고 가정해봅시다.

동일한 저장소에 저장된 .gitlab/secret-detection-ruleset.toml 구성 파일에 다음을 추가하십시오. value를 확장된 구성 파일의 경로로 조정하십시오:

# .gitlab/secret-detection-ruleset.toml
[secrets]
  [[secrets.passthrough]]
    type   = "file"
    target = "gitleaks.toml"
    value  = "extended-gitleaks-config.toml"

extended-gitleaks-config.toml 파일에 다음을 추가하십시오. 사용하고자 하는 정규 표현식과 함께 [[rules]] 섹션을 새로 만들어야 합니다:

# extended-gitleaks-config.toml
[extend]
# 기본 패키지된 규칙 집합을 확장함, 참고: 경로를 변경하지 마십시오.
path = "/gitleaks.toml"

[[rules]]
  description = "일반적인 비밀번호 규칙"
  id = "generic-password"
  regex = '''(?i)(?:pwd|passwd|password)(?:[0-9a-z\-_\t .]{0,20})(?:[\s|']|[\s|"]){0,3}(?:=|>|=:|:{1,3}=|\|\|:|<=|=>|:|\?=)(?:'|\"|\s|=|\x60){0,5}([0-9a-z\-_.=\S_]{3,50})(?:['|\"|\n|\r|\s|\x60|;]|$)'''
  entropy = 3.5
  keywords = ["pwd", "passwd", "password"]

참고: 이 예시 구성은 편의만을 위해 제공되었을 뿐, 모든 사용 사례에 대해 작동하지는 않을 수 있습니다. 복잡한 문자열을 감지하도록 규칙 집합을 구성하면 거짓 양성률이 높아질 수 있거나 특정 패턴을 포착하지 못할 수 있습니다.

사용 가능한 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 구성

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

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

로컬 파이프라인 시크릿 감지 분석기 이미지 사용

GitLab 컨테이너 레지스트리 대신 로컬 Docker 레지스트리에서 이미지를 가져오려면 로컬 파이프라인 시크릿 감지 분석기 이미지를 사용하세요.

전제 조건:

로컬 오프라인 Docker 레지스트리로 Docker 이미지를 가져오는 것은 네트워크 보안 정책에 따라 달라집니다. 외부 리소스에 액세스하는 수락된 방법을 찾기 위해 IT 직원과 상의하세요.

기본 파이프라인 시크릿 감지 분석기 이미지를 registry.gitlab.com에서 로컬 Docker 컨테이너 레지스트리로 가져옵니다:
```
registry.gitlab.com/security-products/secrets:4
```
파이프라인 시크릿 감지 분석기 이미지는 주기적으로 업데이트되므로 로컬 복사본을 주기적으로 업데이트해야 합니다.

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 값은 인증서의 텍스트 표현이어야 합니다.

데모

이러한 구성 옵션 중 일부를 설명하는 데모 프로젝트가 있습니다.

아래는 데모 프로젝트 및 해당 작업 목록이 포함된 표입니다:

동작/작업 흐름	적용 대상/방식	내부 또는 로컬 규칙 집합 사용 여부	원격 규칙 집합 사용 여부
규칙 비활성화	미리 정의된 규칙	로컬 규칙 집합 / 프로젝트 사용	원격 규칙 집합 / 프로젝트 사용
규칙 재정의	미리 정의된 규칙	로컬 규칙 집합 / 프로젝트 사용	원격 규칙 집합 / 프로젝트 사용
기본 규칙집합 교체	파일 전달	로컬 규칙 집합 / 프로젝트 사용	해당 없음
기본 규칙집합 교체	Raw Passthrough	인라인 규칙 집합 / 프로젝트 사용	해당 없음
기본 규칙집합 교체	Git Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용
기본 규칙집합 교체	URL Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용
기본 규칙집합 확장	파일 전달	로컬 규칙 집합 / 프로젝트 사용	해당 없음
기본 규칙집합 확장	Git Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용
기본 규칙집합 확장	URL Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용
경로 무시	파일 전달	로컬 규칙 집합 / 프로젝트 사용	해당 없음
경로 무시	Git Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용
경로 무시	URL Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용
패턴 무시	파일 전달	로컬 규칙 집합 / 프로젝트 사용	해당 없음
패턴 무시	Git Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용
패턴 무시	URL Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용
값 무시	파일 전달	로컬 규칙 집합 / 프로젝트 사용	해당 없음
값 무시	Git Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용
값 무시	URL Passthrough	해당 없음	원격 규칙 집합 / 프로젝트 사용

또한 원격 규칙집합 설정 방법에 대해 설명하는 비디오 데모가 있습니다:

로컬 및 원격 규칙 집합을 사용한 비밀 감지

FIPS 활성화된 이미지

14.10 GitLab에서 도입되었습니다.

기본 스캐너 이미지는 크기와 유지 관리를 위해 기본 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

문제 해결

디버그 수준 로깅

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

경고: `gl-secret-detection-report.json: 일치하는 파일 없음`

이에 대한 정보는 일반 Application Security 문제 해결 섹션을 참조하십시오.

오류: `gitleaks 명령을 실행할 수 없음: 종료 상태 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] ▶ gitleaks 명령을 실행할 수 없음: 종료 상태 2
[ERRO] [secrets] [2020-11-18T18:05:52Z] ▶ Gitleaks 분석 실패: 종료 상태 2

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

secret_detection:
  variables:
    GIT_DEPTH: 100

오류: `ERR fatal: 모호한 인수`

파이프라인 시크릿 검색은 레포지토리의 기본 브랜치가 작업을 트리거한 브랜치와 관련이 없는 경우 ERR fatal: 모호한 인수 오류로 실패할 수 있습니다. 자세한 내용은 이슈 !352014를 참조하십시오.

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

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

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

경고

유출된 시크릿 대응

시크릿이 감지되면 즉시 로테이션해야 합니다. GitLab은 일부 유출된 시크릿을 자동으로 폐기하려고 합니다. 자동으로 폐기되지 않는 시크릿의 경우 수동으로 폐기해야 합니다.

레포지토리의 이력에서 시크릿 삭제는 유출을 완전히 해결하지 않습니다. 원래 시크릿은 레포지토리의 기존 포크나 클론에 그대로 남아 있습니다.

파이프라인 비밀 감지

감지된 비밀

커버리지

전체 히스토리 파이프라인 비밀 감지

고급 취약점 추적

지원되지 않는 워크플로우

출력

구성

요구 사항

분석기 활성화

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

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

분석기 설정 사용자 정의

새로운 패턴 추가

특정 분석기 버전에 고정

전체 히스토리 스캔 활성화

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

분석기 작업 재정의

분석기 규칙 집합 사용자 정의

규칙 집합 구성 파일 생성

기본 규칙세트 수정

기본 규칙 집합 대체

내장 규칙 집합으로

로컬 규칙 집합으로

원격 규칙 집합으로

비공개 원격 규칙 집합으로

기본 규칙 집합 확장

로컬 규칙 집합을 사용하는 경우

원격 규칙 집합을 사용하는 경우

Patron 및 경로 무시

비밀번호 무시

복잡한 문자열 감지

사용 가능한 CI/CD 변수

오프라인 구성

GitLab Runner 구성

로컬 파이프라인 시크릿 감지 분석기 이미지 사용

사용자 정의 SSL CA(인증 기관) 인증서 사용

데모

FIPS 활성화된 이미지

문제 해결

디버그 수준 로깅

경고: gl-secret-detection-report.json: 일치하는 파일 없음

오류: gitleaks 명령을 실행할 수 없음: 종료 상태 2

오류: ERR fatal: 모호한 인수

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

경고

유출된 시크릿 대응

도움말

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

도움받기

경고: `gl-secret-detection-report.json: 일치하는 파일 없음`

오류: `gitleaks 명령을 실행할 수 없음: 종료 상태 2`

오류: `ERR fatal: 모호한 인수`

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