파이프라인 시크릿 탐지는 Git 리포지터리에 커밋되어 GitLab 에 푸시된 파일을 스캔합니다.

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

GitLab Ultimate 에서는 파이프라인 시크릿 탐지 결과가 추가로 처리되므로 다음을 할 수 있습니다:

• 머지 리퀘스트 보고서, 파이프라인 보안 보고서, 취약점 보고서에서 결과를 확인합니다.
• 승인 워크플로에서 결과를 사용합니다.
• 보안 대시보드에서 결과를 검토합니다.
• 공개 리포지터리의 유출에 자동으로 대응합니다.
• 보안 정책을 사용해 프로젝트 전반에 일관된 시크릿 탐지 규칙을 적용합니다.

이 파이프라인 시크릿 탐지 문서를 대화형으로 읽고 사용법을 익히는 데모는 다음을 참고합니다:

• GitLab 애플리케이션 보안에서 시크릿 탐지를 활성화하는 방법 1/2
• GitLab 애플리케이션 보안에서 시크릿 탐지를 활성화하는 방법 2/2

그 밖의 대화형 읽기 자료와 사용법 데모는 GitLab 애플리케이션 보안 시작하기 플레이리스트를 참고합니다.

가용성#

GitLab 티어에 따라 사용할 수 있는 기능이 다릅니다.

시작하기#

파이프라인 시크릿 탐지를 시작하려면 파일럿 프로젝트를 선택하고 분석기를 활성화합니다.

사전 요구 사항:

• docker 또는 kubernetes 실행기를 사용하는 Linux 기반 러너가 있습니다. GitLab.com 의 호스팅 러너를 사용한다면 기본적으로 활성화되어 있습니다.
  • Windows 러너는 지원되지 않습니다.
  • amd64 이외의 CPU 아키텍처는 지원되지 않습니다.
• test Stage 가 포함된 .gitlab-ci.yml 파일이 있습니다.

다음 중 하나를 사용해 시크릿 탐지 분석기를 활성화합니다:

• .gitlab-ci.yml 파일을 직접 편집합니다. CI/CD 구성이 복잡하다면 이 방법을 사용합니다.
• 자동으로 구성된 머지 리퀘스트를 사용합니다. CI/CD 구성이 없거나 최소한이라면 이 방법을 사용합니다.
• 스캔 실행 정책에서 파이프라인 시크릿 탐지를 활성화합니다.

프로젝트에서 시크릿 탐지 스캔을 처음 실행한다면, 분석기를 활성화한 직후에 기록 스캔을 실행하는 것이 좋습니다.

파이프라인 시크릿 탐지를 활성화한 다음에는 분석기 설정을 사용자 지정할 수 있습니다.

.gitlab-ci.yml 파일 직접 편집#

이 방법은 기존 .gitlab-ci.yml 파일을 직접 편집해야 합니다.

1. 상단 바에서 Search or go to 를 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 Build > Pipeline editor 를 선택합니다.

3. 다음 내용을 .gitlab-ci.yml 파일 맨 아래에 복사해 붙여 넣습니다:

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

4. Validate 탭을 선택한 다음 Validate pipeline 을 선택합니다. Simulation completed successfully 메시지는 파일이 유효하다는 뜻입니다.

5. Edit 탭을 선택합니다.

6. 선택 사항. Commit message 텍스트 박스에서 커밋 메시지를 원하는 대로 바꿉니다.

7. Branch 텍스트 박스에 기본 브랜치 이름을 입력합니다.

8. Commit changes 를 선택합니다.

이제 파이프라인에 파이프라인 시크릿 탐지 job 이 포함됩니다. 분석기를 활성화한 다음 기록 스캔 실행을 검토합니다.

자동으로 구성된 머지 리퀘스트 사용#

이 방법은 파이프라인 시크릿 탐지 템플릿을 포함하는 .gitlab-ci.yml 파일을 추가하는 머지 리퀘스트를 자동으로 준비합니다. 이 머지 리퀘스트를 머지하면 파이프라인 시크릿 탐지가 활성화됩니다.

파이프라인 시크릿 탐지를 활성화하려면 다음 단계를 따릅니다.

1. 상단 바에서 Search or go to 를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Secure > Security configuration 을 선택합니다.
3. Pipeline secret detection 행에서 Configure with a merge request 를 선택합니다.
4. 선택 사항. 필드를 입력합니다.
5. Create merge request 를 선택합니다.
6. 머지 리퀘스트를 검토하고 머지합니다.

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

커버리지#

파이프라인 시크릿 탐지는 커버리지와 실행 시간의 균형을 맞추도록 최적화되어 있습니다. 시크릿을 찾기 위해 스캔하는 대상은 리포지터리의 현재 상태와 이후 커밋뿐입니다. 리포지터리 기록에 이미 있는 시크릿을 식별하려면 파이프라인 시크릿 탐지를 활성화한 뒤 기록 스캔을 한 번 실행합니다. 스캔 결과는 파이프라인이 완료된 뒤에만 확인할 수 있습니다.

시크릿을 찾기 위해 정확히 무엇을 스캔하는지는 파이프라인 유형과 추가 구성 설정 여부에 따라 달라집니다.

기본적으로 파이프라인을 실행하면 다음과 같이 동작합니다:

• 브랜치에서:

  • 기본 브랜치에서:

    • 분석기 버전 v7.38.1 이상에서는 미리 정의된 CI/CD 변수 CI_COMMIT_BEFORE_SHA 로 유효한 이전 커밋을 확인할 수 있으면, 이전 커밋부터 현재 커밋까지 모든 커밋의 내용을 스캔합니다.
    • 유효한 이전 커밋이 없으면(예를 들어 새 리포지터리에 처음 푸시한 커밋) Git 작업 트리의 내용을 스캔합니다.

  • 기능 브랜치에서:

    • 분석기 버전 v7.35.0 이상에서는 머지 베이스부터 최신 커밋까지 모든 커밋의 내용(브랜치가 분기된 뒤 그 브랜치에만 있는 모든 커밋)을 스캔합니다. 이 동작은 머지 베이스를 확인할 수 있는 모든 기능 브랜치 파이프라인에 적용됩니다.
    • GitLab 19.1 이상은 미리 정의된 CI 변수 CI_COMMIT_DEFAULT_BRANCH_BASE_SHA 로 머지 베이스 SHA 를 제공합니다.
    • GitLab 19.1 보다 이전 버전이거나 머지 베이스를 확인할 수 없으면 분석기는 이전 동작으로 대체됩니다:
      • 새 기능 브랜치에서는 최신 커밋만 스캔합니다. 브랜치의 이전 커밋은 스캔에 포함되지 않습니다.
      • 기존 기능 브랜치에서는 마지막으로 푸시한 커밋 이후부터 최신 커밋까지 모든 커밋을 스캔합니다.

    [!note] 브랜치 분기점 이후의 모든 커밋을 매번 스캔하려면 머지 리퀘스트 파이프라인을 활성화합니다.

• 머지 리퀘스트에서는 브랜치에 있는 모든 커밋의 내용을 스캔합니다. 분석기가 모든 커밋에 접근할 수 없으면 부모 커밋부터 최신 커밋까지 모든 커밋의 내용을 스캔합니다. 모든 커밋을 스캔하려면 머지 리퀘스트 파이프라인을 활성화해야 합니다.

기본 동작을 재정의하려면 사용 가능한 CI/CD 변수를 사용합니다.

분석기가 커밋을 가져오는 방식#

기본적으로 GitLab 이 리포지터리를 처음 클론할 때는 가장 최근 커밋만 가져옵니다(「얕은 클론」). 이 초기 클론을 넘어 추가 커밋이 필요하면 분석기가 최적화된 전략으로 자동으로 가져옵니다:

• 머지 리퀘스트에서는 분석기가 머지 베이스 이후에 커밋된 변경 사항만 가져와 데이터 전송을 최소화합니다.
• --since 나 --max-count 같은 로그 옵션을 지정하면 분석기는 필요한 커밋만 가져옵니다.
• 기록 스캔 중에는 분석기가 리포지터리 기록 전체를 가져옵니다. 리포지터리를 얕게 클론했다면 분석기는 --unshallow 옵션을 사용합니다.

분석기가 필요한 커밋을 가져올 수 없으면 확보한 데이터를 스캔하는 방식으로 대체됩니다:

• 강제 푸시 이후에는 분석기가 리포지터리의 현재 상태만 스캔합니다.
• 네트워크 장애가 있으면 분석기는 초기 클론 이후 확보한 커밋을 스캔합니다.
• 타임아웃이 발생하면 분석기는 부분적인 커밋 기록으로 스캔을 계속합니다.

이러한 대체 동작은 제한된 환경에서도 파이프라인이 성공적으로 완료되도록 보장합니다.

초기 리포지터리 클론 깊이#

러너의 GIT_DEPTH는 처음에 클론할 커밋 수를 제어합니다. 파이프라인 시크릿 탐지는 필요할 때 추가 커밋을 자동으로 가져오므로, 보통 이 설정을 조정할 필요가 없습니다.

제한된 네트워크 환경에서 커밋 누락 문제가 계속 발생한다면 문제 해결 절에서 우회 방법을 참고합니다.

기록 스캔 실행#

기본적으로 파이프라인 시크릿 탐지는 Git 리포지터리의 현재 상태만 스캔합니다. 리포지터리 기록에 들어 있는 시크릿은 탐지되지 않습니다. Git 리포지터리의 모든 커밋과 브랜치에서 시크릿을 확인하려면 기록 스캔을 실행합니다.

기록 스캔은 파이프라인 시크릿 탐지를 활성화한 뒤 한 번만 실행하는 것이 좋습니다. 기록 스캔은 시간이 오래 걸릴 수 있으며, Git 기록이 긴 대규모 리포지터리에서는 특히 그렇습니다. 초기 기록 스캔을 완료한 다음에는 파이프라인의 일부로 표준 파이프라인 시크릿 탐지만 사용합니다.

스캔 실행 정책으로 파이프라인 시크릿 탐지를 활성화하면 기본적으로 첫 예약 스캔이 기록 스캔으로 실행됩니다.

기록 스캔을 실행하려면 다음 단계를 따릅니다.

1. 상단 바에서 Search or go to 를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Build > Pipelines 를 선택합니다.
3. New pipeline 을 선택합니다.
4. CI/CD 변수를 추가합니다:
   1. 드롭다운 목록에서 Variable 을 선택합니다.
   2. Input variable key 박스에 SECRET_DETECTION_HISTORIC_SCAN 을 입력합니다.
   3. Input variable value 박스에 true 를 입력합니다.
5. New pipeline 을 선택합니다.

중복 취약점 추적#

히스토리

• GitLab 17.0 에서 도입되었습니다.

시크릿 탐지는 고급 취약점 추적 알고리즘을 사용해, 파일을 리팩터링하거나 이동할 때 중복된 발견 항목과 취약점이 생성되지 않도록 막습니다.

다음과 같은 경우에는 새 발견 항목이 생성되지 않습니다:

• 파일 안에서 시크릿이 이동한 경우.
• 파일 안에 같은 시크릿이 중복해 나타나는 경우.

중복 취약점 추적은 파일 단위로 동작합니다. 같은 시크릿이 서로 다른 두 파일에 나타나면 발견 항목이 두 개 생성됩니다.

자세한 내용은 비공개 프로젝트 https://gitlab.com/gitlab-org/security-products/post-analyzers/tracking-calculator 를 참고합니다. 이 프로젝트는 GitLab 팀 멤버만 이용할 수 있습니다.

지원되지 않는 워크플로#

중복 취약점 추적은 다음과 같은 워크플로를 지원하지 않습니다:

• 기존 발견 항목에 추적 서명이 없고, 새 발견 항목과 같은 위치를 공유하지 않는 경우.

• 특정 시크릿을 전체 시크릿 값이 아니라 접두사로 검색해 탐지하는 경우. 이러한 시크릿 유형에서는 같은 파일에 있는 같은 유형의 모든 탐지가 하나의 발견 항목으로 보고됩니다.

  예를 들어 SSH 개인 키는 접두사 -----BEGIN OPENSSH PRIVATE KEY----- 로 탐지합니다. 같은 파일에 SSH 개인 키가 여러 개 있으면 파이프라인 시크릿 탐지는 발견 항목을 하나만 생성합니다.

• 기록 스캔을 실행하거나 기존 커밋에 파이프라인 시크릿 탐지를 활성화할 때, 같은 스캔에서 한 커밋에 시크릿이 도입되고 이후 커밋에서 수정되면 취약점 보고서에는 가장 최근 시크릿 값만 표시됩니다.

탐지된 시크릿#

파이프라인 시크릿 탐지는 특정 패턴을 찾아 리포지터리 콘텐츠를 스캔합니다. 각 패턴은 특정 유형의 시크릿과 일치하며 TOML 구문으로 규칙에 지정됩니다. 기본 규칙 집합은 GitLab 이 관리합니다.

GitLab Ultimate 에서는 필요에 맞게 이 규칙을 확장할 수 있습니다. 예를 들어 사용자 지정 접두사를 쓰는 개인 액세스 토큰은 기본적으로 탐지되지 않지만, 이러한 토큰을 식별하도록 규칙을 사용자 지정할 수 있습니다. 자세한 내용은 분석기 룰셋 사용자 지정을 참고합니다.

파이프라인 시크릿 탐지가 어떤 시크릿을 탐지하는지는 탐지된 시크릿을 참고합니다. 파이프라인 시크릿 탐지는 신뢰도 높은 결과를 제공하기 위해 비밀번호나 그 밖의 구조화되지 않은 시크릿을 URL 과 같은 특정 컨텍스트에서만 찾습니다.

시크릿이 탐지되면 해당 시크릿에 대한 취약점이 생성됩니다. 스캔한 파일에서 시크릿을 제거하고 파이프라인 시크릿 탐지를 다시 실행해도 취약점은 "Still detected" 상태로 남습니다. 유출된 시크릿은 폐기될 때까지 계속 보안 위험으로 남기 때문입니다. 제거한 시크릿도 Git 기록에는 그대로 남습니다. Git 리포지터리 기록에서 시크릿을 제거하려면 리포지터리에서 텍스트 삭제를 참고합니다.

제외되는 항목#

성능을 높이기 위해 파이프라인 시크릿 탐지는 시크릿이 들어 있을 가능성이 낮은 특정 파일 유형과 디렉터리를 자동으로 제외합니다.

제외되는 항목은 다음과 같습니다:

시크릿 탐지 결과#

파이프라인 시크릿 탐지는 gl-secret-detection-report.json 파일을 job 아티팩트로 출력합니다. 이 파일에는 탐지된 시크릿이 담겨 있습니다. GitLab 밖에서 처리하려면 파일을 다운로드할 수 있습니다.

자세한 내용은 보고서 파일 스키마와 보고서 파일 예시를 참고합니다.

추가 출력#

job 결과는 다음에도 보고됩니다:

• 머지 리퀘스트 보고서: 머지 리퀘스트에서 새로 도입된 발견 항목을 표시합니다.
• 파이프라인 보안 보고서: 가장 최근 파이프라인 실행의 모든 발견 항목을 표시합니다.
• 취약점 보고서: 모든 보안 발견 항목을 중앙에서 관리합니다.
• 보안 대시보드: 프로젝트와 그룹 전반의 모든 취약점을 조직 차원에서 확인할 수 있습니다.

결과 이해#

파이프라인 시크릿 탐지는 리포지터리에서 발견한 시크릿 후보에 대한 자세한 정보를 제공합니다. 각 시크릿에는 유출된 시크릿의 유형과 해결 지침이 포함됩니다.

결과를 검토할 때는 다음 순서로 진행합니다:

1. 주변 코드를 살펴보고 탐지된 패턴이 실제로 시크릿인지 판단합니다.
2. 탐지된 값이 실제로 동작하는 자격 증명인지 테스트합니다.
3. 리포지터리의 공개 범위와 시크릿의 사용 범위를 고려합니다.
4. 활성 상태이고 권한이 높은 시크릿을 먼저 처리합니다.

일반적인 탐지 카테고리#

파이프라인 시크릿 탐지의 탐지 결과는 대부분 다음 세 가지 카테고리 중 하나에 속합니다:

• 참 양성: 교체하고 제거해야 하는 실제 시크릿입니다. 예를 들면 다음과 같습니다:
  • 활성 API 키, 데이터베이스 비밀번호, 인증 토큰
  • 개인 키와 인증서
  • 서비스 계정 자격 증명
• 거짓 양성: 실제 시크릿이 아닌데 탐지된 패턴입니다. 예를 들면 다음과 같습니다:
  • 문서의 예시 값
  • 테스트 데이터나 모의 자격 증명
  • 플레이스홀더 값이 들어간 구성 템플릿
• 과거 발견 항목: 이전에 커밋되었으나 지금은 활성 상태가 아닐 수 있는 시크릿입니다. 이러한 탐지 결과는 다음과 같습니다:
  • 현재 상태를 확인하기 위한 조사가 필요합니다
  • 예방 차원에서 그래도 교체해야 합니다

유출된 시크릿 해결#

시크릿이 탐지되면 즉시 교체해야 합니다. GitLab 은 일부 유형의 유출된 시크릿을 자동으로 폐기하려고 시도합니다. 자동으로 폐기되지 않는 시크릿은 직접 폐기해야 합니다.

리포지터리 기록에서 시크릿을 완전히 제거해도 유출이 완전히 해결되지는 않습니다. 원래 시크릿은 리포지터리의 기존 포크나 클론에 그대로 남습니다.

유출된 시크릿에 대응하는 방법은 취약점 보고서에서 해당 취약점을 선택해 확인합니다.

최적화#

조직 전체에 파이프라인 시크릿 탐지를 배포하기 전에, 해당 환경에 맞춰 거짓 양성을 줄이고 정확도를 높이도록 구성을 최적화합니다.

거짓 양성은 경보 피로를 유발하고 도구에 대한 신뢰를 떨어뜨립니다. 사용자 지정 룰셋 구성(Ultimate 전용)을 검토합니다:

• 코드베이스에 특정한, 안전하다고 알려진 패턴을 제외합니다.
• 시크릿이 아닌 값에서 자주 트리거되는 규칙의 민감도를 조정합니다.
• 조직에 고유한 시크릿 형식에 대한 사용자 지정 규칙을 추가합니다.

대규모 리포지터리나 프로젝트가 많은 조직에서 성능을 최적화하려면 다음을 검토합니다:

• 스캔 범위 관리:
  • 프로젝트에서 기록 스캔을 한 번 실행한 다음에는 기록 스캔을 끕니다.
  • 사용량이 적은 시간대에 기록 스캔을 예약합니다.
• 리소스 할당:
  • 대규모 리포지터리에는 충분한 러너 리소스를 할당합니다.
  • 보안 스캔 워크로드용 전용 러너를 검토합니다.
  • 스캔 소요 시간을 모니터링하고 리포지터리 크기에 맞춰 최적화합니다.

최적화 변경 사항 테스트#

조직 전체에 최적화를 적용하기 전에 다음을 수행합니다:

1. 최적화 때문에 실제 시크릿을 놓치지 않는지 검증합니다.
2. 거짓 양성 감소량과 스캔 성능 개선을 추적합니다.
3. 효과가 있었던 최적화 패턴을 기록으로 남깁니다.

도입#

파이프라인 시크릿 탐지는 점진적으로 구현하는 것이 좋습니다. 조직 전체에 기능을 도입하기 전에 소규모 파일럿으로 시작해 도구의 동작을 파악합니다.

파이프라인 시크릿 탐지를 도입할 때는 다음 지침을 따릅니다:

1. 파일럿 프로젝트를 선택합니다. 적합한 프로젝트는 다음 조건을 갖추고 있습니다:
   • 정기적인 커밋이 이어지는 활발한 개발.
   • 관리할 수 있는 규모의 코드베이스.
   • GitLab CI/CD 에 익숙한 팀.
   • 구성을 반복해 다듬을 의지.
2. 간단하게 시작합니다. 파일럿 프로젝트에서 기본 설정으로 파이프라인 시크릿 탐지를 활성화합니다.
3. 결과를 모니터링합니다. 일반적인 발견 항목을 파악하기 위해 1~2주 동안 분석기를 실행합니다.
4. 탐지된 시크릿을 처리합니다. 발견된 실제 시크릿을 해결합니다.
5. 구성을 조정합니다. 초기 결과에 따라 설정을 조정합니다.
6. 구현 내용을 문서화합니다. 자주 나오는 거짓 양성과 해결 패턴을 기록합니다.

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

문제 해결#

디버그 수준 로깅#

문제를 해결할 때 디버그 수준 로깅이 도움이 됩니다. 자세한 내용은 디버그 수준 로깅을 참고합니다.

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

이에 관한 내용은 애플리케이션 보안 문제 해결 일반 절을 참고합니다.

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

이 오류는 분석기가 필요한 커밋에 접근할 수 없다는 뜻입니다. 대부분의 경우 분석기가 누락된 커밋을 자동으로 가져오지만, 제한된 환경에서는 문제가 발생할 수 있습니다.

원인을 진단하려면 디버그 수준 로깅을 활성화하고 다음을 확인합니다:

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

이 문제를 해결하는 방법은 다음과 같습니다:

• 대부분의 경우 조치가 필요하지 않습니다. 분석기가 자동으로 가져오도록 둡니다.

• 제한된 네트워크에서는 초기 클론 깊이를 늘립니다:

  secret_detection:
    variables:
      GIT_DEPTH: 100  # or 0 to clone everything
  

• 대규모 리포지터리에서는 스캔 범위를 제한합니다:

  secret_detection:
    variables:
      SECRET_DETECTION_LOG_OPTIONS: "--max-count=50"
  

오류: ERR fatal: ambiguous argument#

리포지터리의 기본 브랜치가 job 을 트리거한 브랜치와 관련이 없으면 파이프라인 시크릿 탐지가 ERR fatal: ambiguous argument 메시지와 함께 실패할 수 있습니다. 자세한 내용은 이슈 !352014를 참고합니다.

이 문제를 해결하려면 리포지터리에서 기본 브랜치를 올바르게 설정합니다. secret-detection job 을 실행하는 브랜치와 관련된 기록을 가진 브랜치로 설정해야 합니다.

job 로그의 exec /bin/sh: exec format error 메시지#

GitLab 파이프라인 시크릿 탐지 분석기는 amd64 CPU 아키텍처에서 실행하는 것만 지원합니다. 이 메시지는 job 이 arm 처럼 다른 아키텍처에서 실행되고 있다는 뜻입니다.

오류: fatal: detected dubious ownership in repository at '/builds/<project dir>'#

시크릿 탐지가 종료 상태 128 로 실패할 수 있습니다. Docker 이미지의 사용자가 변경되어 발생할 수 있습니다.

예를 들면 다음과 같습니다:

$ /analyzer run
[INFO] [secrets] [2024-06-06T07:28:13Z] ▶ GitLab secrets analyzer v6.0.1
[INFO] [secrets] [2024-06-06T07:28:13Z] ▶ Detecting project
[INFO] [secrets] [2024-06-06T07:28:13Z] ▶ Analyzer will attempt to analyze all projects in the repository
[INFO] [secrets] [2024-06-06T07:28:13Z] ▶ Loading ruleset for /builds....
[WARN] [secrets] [2024-06-06T07:28:13Z] ▶ /builds/....secret-detection-ruleset.toml not found, ruleset support will be disabled.
[INFO] [secrets] [2024-06-06T07:28:13Z] ▶ Running analyzer
[FATA] [secrets] [2024-06-06T07:28:13Z] ▶ get commit count: exit status 128

이 문제를 우회하려면 다음 내용을 담은 before_script 를 추가합니다:

before_script:
    - git config --global --add safe.directory "$CI_PROJECT_DIR"

이 문제에 관한 자세한 내용은 이슈 465974를 참고합니다.

GIT_DEPTH 를 조정해도 스캔 대상이 바뀌지 않는 문제#

의도된 동작입니다. GIT_DEPTH 는 초기 클론에 쓰이는 러너 변수이며, 분석기 동작을 바꾸지 않습니다.

시크릿 탐지 분석기는 다음을 기준으로 스캔 대상을 결정합니다:

• 파이프라인 유형(푸시, 머지 리퀘스트, 예약)
• 브랜치 컨텍스트(기본, 신규, 기존)
• 사용자의 구성(SECRET_DETECTION_LOG_OPTIONS, SECRET_DETECTION_HISTORIC_SCAN)

예를 들어 커밋 30개만 스캔하려면 다음과 같이 설정합니다:

secret_detection:
  variables:
    # Scan the last 30 commits
    SECRET_DETECTION_LOG_OPTIONS: "--max-count=30"

최근 2주 동안의 커밋만 스캔하려면 다음과 같이 설정합니다:

secret_detection:
  variables:
    # Scan commits made in the last two weeks
    SECRET_DETECTION_LOG_OPTIONS: "--since=2.weeks"

HEAD~10 부터 HEAD 까지의 커밋만 스캔하려면 다음과 같이 설정합니다:

secret_detection:
  variables:
    # Scan commits from HEAD~10 to HEAD
    SECRET_DETECTION_LOG_OPTIONS: "HEAD~10..HEAD"

전체 옵션 목록은 Git log 옵션 문서를 참고합니다.

강제 푸시 탐지#

강제 푸시 이후에는 다음 메시지가 표시될 수 있습니다:

Failed to retrieve all the commits from the last Git push event due to a force push

의도된 동작입니다. 스캔은 현재 리포지터리 상태를 사용해 계속 진행됩니다.

리포지터리 신뢰 구성#

다음 메시지가 표시될 수 있습니다:

Added project directory to Git safe.directory configuration

컨테이너 환경에서 흔히 쓰이는 보안 구성을 나타냅니다. 별도의 조치는 필요하지 않습니다.