파이프라인 시크릿 감지
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
파이프라인 시크릿 감지는 파일이 Git 저장소에 커밋되고 GitLab에 푸시된 후 스캔합니다. 파이프라인 시크릿 감지를 활성화하면 secret_detection이라는 CI/CD 작업에서 스캔이 실행됩니다. GitLab Ultimate에서는 파이프라인 시크릿 감지 결과가 처리되어 다음을 수행할 수 있습니다:
파이프라인 시크릿 감지는 파일이 Git 저장소에 커밋되고 GitLab에 푸시된 후 스캔합니다.
파이프라인 시크릿 감지를 활성화하면 secret_detection이라는 CI/CD 작업에서 스캔이 실행됩니다.
모든 GitLab 티어에서 스캔을 실행하고 파이프라인 시크릿 감지 JSON 보고서 아티팩트를 볼 수 있습니다.
GitLab Ultimate에서는 파이프라인 시크릿 감지 결과가 처리되어 다음을 수행할 수 있습니다:
- Merge request 위젯, 파이프라인 보안 보고서, 취약점 보고서에서 확인합니다.
- 승인 워크플로에서 사용합니다.
- 보안 대시보드에서 검토합니다.
- 공개 저장소의 유출에 자동으로 응답합니다.
- 보안 정책을 사용하여 프로젝트 전반에 일관된 시크릿 감지 규칙을 적용합니다.
이 파이프라인 시크릿 감지 문서의 대화형 읽기 및 데모는 다음을 참조하세요:
다른 대화형 읽기 및 데모는 GitLab 애플리케이션 보안 시작하기 플레이리스트를 참조하세요.
가용성#
다양한 GitLab 티어에서 다양한 기능을 사용할 수 있습니다.
| 기능 | Free 및 Premium | Ultimate |
|---|---|---|
| 분석기 동작 사용자 정의 | ✅ | ✅ |
| 출력 다운로드 | ✅ | ✅ |
| Merge request 위젯에서 새 발견 결과 보기 | ❌ | ✅ |
| 파이프라인의 Security 탭에서 식별된 시크릿 보기 | ❌ | ✅ |
| 취약점 관리 | ❌ | ✅ |
| 보안 대시보드 액세스 | ❌ | ✅ |
| 분석기 룰셋 사용자 정의 | ❌ | ✅ |
| 보안 정책 활성화 | ❌ | ✅ |
시작하기#
파이프라인 시크릿 감지를 시작하려면 파일럿 프로젝트를 선택하고 분석기를 활성화하세요.
사전 요구사항:
docker또는kubernetes실행기가 있는 Linux 기반 러너. GitLab.com의 호스팅된 러너를 사용하는 경우 기본적으로 활성화됩니다.- Windows 러너는 지원되지 않습니다.
- amd64 이외의 CPU 아키텍처는 지원되지 않습니다.
test스테이지를 포함하는.gitlab-ci.yml파일.
다음 중 하나를 사용하여 시크릿 감지 분석기를 활성화하세요:
.gitlab-ci.yml파일을 수동으로 편집합니다. CI/CD 구성이 복잡한 경우 이 방법을 사용하세요.- 자동으로 구성된 Merge request를 사용합니다. CI/CD 구성이 없거나 최소한인 경우 이 방법을 사용하세요.
- 스캔 실행 정책에서 파이프라인 시크릿 감지를 활성화합니다.
프로젝트에서 처음으로 시크릿 감지 스캔을 실행하는 경우, 분석기를 활성화한 직후에 기록 스캔을 실행해야 합니다.
파이프라인 시크릿 감지를 활성화한 후 분석기 설정을 사용자 정의할 수 있습니다.
.gitlab-ci.yml 파일 수동 편집#
이 방법은 기존 .gitlab-ci.yml 파일을 수동으로 편집해야 합니다.
-
상단 표시줄에서 Search or go to를 선택하여 프로젝트를 찾습니다.
-
왼쪽 사이드바에서 Build > Pipeline editor를 선택합니다.
-
.gitlab-ci.yml파일의 하단에 다음을 복사하여 붙여넣습니다:include: - template: Jobs/Secret-Detection.gitlab-ci.yml -
Validate 탭을 선택한 다음 Validate pipeline을 선택합니다. Simulation completed successfully 메시지는 파일이 유효함을 나타냅니다.
-
Edit 탭을 선택합니다.
-
선택 사항. Commit message 텍스트 박스에서 커밋 메시지를 사용자 정의합니다.
-
Branch 텍스트 박스에 기본 브랜치 이름을 입력합니다.
-
Commit changes를 선택합니다.
이제 파이프라인에 파이프라인 시크릿 감지 작업이 포함됩니다. 분석기를 활성화한 후 기록 스캔 실행을 고려하세요.
자동으로 구성된 Merge request 사용#
이 방법은 파이프라인 시크릿 감지 템플릿이 포함된 .gitlab-ci.yml 파일을 추가하기 위한 Merge request를 자동으로 준비합니다. Merge request를 머지하여 파이프라인 시크릿 감지를 활성화하세요.
파이프라인 시크릿 감지를 활성화하려면:
- 상단 표시줄에서 Search or go to를 선택하여 프로젝트를 찾습니다.
- 왼쪽 사이드바에서 Secure > Security configuration을 선택합니다.
- Pipeline secret detection 행에서 Configure with a merge request를 선택합니다.
- 선택 사항. 필드를 완성합니다.
- Create merge request를 선택합니다.
- Merge request를 검토하고 머지합니다.
이제 파이프라인에 파이프라인 시크릿 감지 작업이 포함됩니다.
커버리지#
파이프라인 시크릿 감지는 커버리지와 실행 시간의 균형을 맞추도록 최적화됩니다. 저장소의 현재 상태와 향후 커밋만 시크릿에 대해 스캔됩니다. 저장소 기록에 이미 있는 시크릿을 식별하려면 파이프라인 시크릿 감지를 활성화한 후 한 번 기록 스캔을 실행하세요. 스캔 결과는 파이프라인이 완료된 후에만 사용할 수 있습니다.
스캔되는 내용은 파이프라인 유형과 추가 구성 설정 여부에 따라 다릅니다.
기본적으로 파이프라인을 실행할 때:
- 브랜치에서:
- 기본 브랜치에서는 Git 작업 트리가 스캔됩니다. 즉, 현재 저장소 상태가 일반 디렉토리인 것처럼 스캔됩니다.
- 새 비기본 브랜치에서는 최신 커밋의 내용만 스캔됩니다. 브랜치의 이전 커밋은 스캔에 포함되지 않습니다.
- 기존 비기본 브랜치에서는 마지막으로 푸시된 커밋 이후의 모든 커밋 내용부터 최신 커밋까지 스캔됩니다.
- 브랜치 분기점에서 매번 모든 커밋을 스캔하려면 Merge request 파이프라인을 활성화하세요.
- Merge request에서는 브랜치의 모든 커밋 내용이 스캔됩니다. 분석기가 모든 커밋에 액세스할 수 없는 경우 부모에서 최신 커밋까지의 모든 커밋 내용이 스캔됩니다. 모든 커밋을 스캔하려면 Merge request 파이프라인을 활성화해야 합니다.
기본 동작을 재정의하려면 사용 가능한 CI/CD 변수를 사용하세요.
분석기의 커밋 가져오기 방식#
기본적으로 GitLab이 저장소를 처음 클론할 때 가장 최근의 커밋만 가져옵니다("얕은 클론"). 이 초기 클론을 넘어 추가 커밋이 필요한 경우 분석기는 최적화된 전략을 사용하여 자동으로 가져옵니다:
- Merge request의 경우 분석기는 병합 기반 이후에 커밋된 변경 사항만 검색하여 데이터 전송을 최소화합니다.
--since또는--max-count와 같은 로그 옵션이 지정된 경우 분석기는 필요한 커밋만 가져옵니다.- 기록 스캔 중에 분석기는 전체 저장소 기록을 가져옵니다. 저장소가 얕게 클론된 경우 분석기는
--unshallow옵션을 사용합니다.
분석기가 필요한 커밋을 가져올 수 없는 경우 사용 가능한 데이터 스캔으로 대체됩니다:
- 강제 푸시 후 분석기는 저장소의 현재 상태만 스캔합니다.
- 네트워크 장애가 있는 경우 분석기는 초기 클론 후 사용 가능한 커밋을 스캔합니다.
- 타임아웃이 있는 경우 분석기는 부분적인 커밋 기록으로 스캔을 계속합니다.
이러한 대체 방법은 제한된 환경에서도 파이프라인이 성공적으로 완료되도록 보장합니다.
초기 저장소 클론 깊이#
러너의 GIT_DEPTH는 처음에 클론되는 커밋 수를 제어합니다. 파이프라인 시크릿 감지는 필요할 때 추가 커밋을 자동으로 가져오므로 일반적으로 이 설정을 조정할 필요가 없습니다.
제한된 네트워크 환경에서 누락된 커밋으로 인해 지속적인 문제가 발생하는 경우 해결 방법에 대한 트러블슈팅을 참조하세요.
기록 스캔 실행#
기본적으로 파이프라인 시크릿 감지는 Git 저장소의 현재 상태만 스캔합니다. 저장소 기록에 포함된 시크릿은 감지되지 않습니다. Git 저장소의 모든 커밋과 브랜치에서 시크릿을 확인하기 위해 기록 스캔을 실행하세요.
파이프라인 시크릿 감지를 활성화한 후 한 번만 기록 스캔을 실행해야 합니다. 기록 스캔은 특히 Git 기록이 긴 대규모 저장소의 경우 시간이 많이 걸릴 수 있습니다. 초기 기록 스캔을 완료한 후에는 파이프라인의 일부로 표준 파이프라인 시크릿 감지만 사용하세요.
스캔 실행 정책으로 파이프라인 시크릿 감지를 활성화하면 기본적으로 첫 번째 예약된 스캔은 기록 스캔입니다.
기록 스캔을 실행하려면:
- 상단 표시줄에서 Search or go to를 선택하여 프로젝트를 찾습니다.
- 왼쪽 사이드바에서 Build > Pipelines를 선택합니다.
- New pipeline을 선택합니다.
- CI/CD 변수를 추가합니다:
- 드롭다운 목록에서 Variable을 선택합니다.
- Input variable key 박스에
SECRET_DETECTION_HISTORIC_SCAN을 입력합니다. - Input variable value 박스에
true를 입력합니다.
- 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과 같은 특정 컨텍스트에서만 비밀번호나 기타 비구조화 시크릿을 찾습니다.
시크릿이 감지되면 취약점이 생성됩니다. 스캔된 파일에서 시크릿이 제거되고 파이프라인 시크릿 감지가 다시 실행된 경우에도 취약점은 "여전히 감지됨"으로 남아 있습니다. 이는 유출된 시크릿이 취소될 때까지 계속해서 보안 위험이기 때문입니다. 제거된 시크릿은 Git 기록에도 남아 있습니다. Git 저장소의 기록에서 시크릿을 제거하려면 저장소에서 텍스트 수정을 참조하세요.
제외된 항목#
성능을 향상시키기 위해 파이프라인 시크릿 감지는 시크릿을 포함할 가능성이 낮은 특정 파일 유형과 디렉토리를 자동으로 제외합니다.
다음 항목이 제외됩니다:
| 카테고리 | 제외된 항목 |
|---|---|
| 구성 파일 | 파일: gitleaks.toml, verification-metadata.xml, Database.refactorlog, .editorconfig, .gitattributes |
| 미디어 및 바이너리 파일 | 확장자: .bmp, .gif, .svg, .jpg/.jpeg, .png, .tiff/.tif, .webp, .ico, .heic폰트: .eot, .otf, .ttf, .woff, .woff2문서: .doc/.docx, .xls/.xlsx, .ppt/.pptx, .pdf오디오/비디오: .mp3, .mp4, .wav, .flac, .aac, .ogg, .avi, .mkv, .mov, .wmv, .flv, .webm아카이브: .zip, .rar, .7z, .tar, .gz, .bz2, .xz, .dmg, .iso실행 파일: .exe, .gltf |
| Visual Studio 파일 | 확장자: .socket, .vsidx, .suo, .wsuo, .dll, .pdb |
| 패키지 잠금 파일 | 파일: deno.lock, npm-shrinkwrap.json, package-lock.json, pnpm-lock.yaml, yarn.lock, Pipfile.lock, poetry.lock, gradle.lockfile, Cargo.lock, composer.lock |
| Go 언어 파일 | 확장자: go.mod, go.sum, go.work, go.work.sum디렉토리: vendor/ (github.com, golang.org, google.golang.org, gopkg.in, istio.io, k8s.io, sigs.k8s.io의 Go 모듈만)파일: vendor/modules.txt |
| Ruby 파일 | 디렉토리: .bundle/, gems/, specifications/확장자: gems/ 디렉토리의 .gem 파일, specifications/ 디렉토리의 .gemspec 파일 |
| 빌드 도구 래퍼 | 파일: gradlew, gradlew.bat, mvnw, mvnw.cmd디렉토리: .mvn/wrapper/특정: Maven 래퍼 디렉토리의 MavenWrapperDownloader.java |
| 의존성 디렉토리 | 디렉토리: node_modules/, bower_components/, packages/ |
| 빌드 출력 디렉토리 | 디렉토리: target/, build/, bin/, obj/ |
| 벤더 디렉토리 | 디렉토리: vendor/bundle/, vendor/ruby/, vendor/composer/ |
| Python 캐시 파일 | 확장자: .pyc, .pyo디렉토리: __pycache__/ |
| Python 도구 캐시 | 디렉토리: .pytest_cache/, .mypy_cache/, .tox/ |
| Python 가상 환경 | 디렉토리: venv/, virtualenv/, .venv/, env/ |
| Python 설치 디렉토리 | 디렉토리: lib/python[version]/, lib64/python[version]/, python[version]/lib/, python[version]/Lib/ |
| Python 패키지 메타데이터 | 버전과 .dist-info로 끝나는 패키지 이름 |
| JavaScript 라이브러리 | 파일: angular*.js, bootstrap*.js, jquery*.js, jquery-ui*.js, plotly*.js, swagger-ui*.js 소스 맵: 해당 .js.map 파일 |
| 최소화/번들된 자산 | 확장자: .min.js, .min.css, .bundle.js, .bundle.css, .map (소스 맵 파일) |
| 컴파일된 파일 | 확장자: .class, .o, .obj, .jar, .war (웹 아카이브), .ear |
| 캐시 디렉토리 | 디렉토리: .cache/, .coverage/, .pytest_cache/, .mypy_cache/, .tox/ |
| 생성된 문서 | 디렉토리: htmlcov/, coverage/, _build/, _site/, docs/_build/ |
| 버전 관리 및 IDE | 디렉토리: .git/, .svn/, .hg/, .bzr/ (버전 관리), .vscode/, .idea/, .eclipse/, .vs/ (IDE) |
| 운영 체제 파일 | 파일: .DS_Store, Thumbs.db |
시크릿 감지 결과#
파이프라인 시크릿 감지는 gl-secret-detection-report.json 파일을 작업 아티팩트로 출력합니다. 이 파일에는 감지된 시크릿이 포함됩니다. GitLab 외부에서 처리하기 위해 파일을 다운로드할 수 있습니다.
자세한 내용은 보고서 파일 스키마와 예제 보고서 파일을 참조하세요.
추가 출력#
작업 결과는 다음에도 보고됩니다:
- Merge request 위젯: Merge request에서 도입된 새 발견 결과를 표시합니다.
- 파이프라인 보안 보고서: 최신 파이프라인 실행의 모든 발견 결과를 표시합니다.
- 취약점 보고서: 모든 보안 발견 결과의 중앙 집중식 관리를 제공합니다.
- 보안 대시보드: 프로젝트 및 그룹 전반에 걸친 모든 취약점에 대한 조직 전체 가시성을 제공합니다.
결과 이해#
파이프라인 시크릿 감지는 저장소에서 발견된 잠재적인 시크릿에 대한 자세한 정보를 제공합니다. 각 시크릿에는 유출된 시크릿 유형과 수정 지침이 포함됩니다.
결과를 검토할 때:
- 주변 코드를 보고 감지된 패턴이 실제로 시크릿인지 확인합니다.
- 감지된 값이 작동하는 자격증명인지 테스트합니다.
- 저장소의 가시성과 시크릿의 범위를 고려합니다.
- 활성, 높은 권한을 가진 시크릿을 먼저 처리합니다.
일반적인 감지 카테고리#
파이프라인 시크릿 감지에 의한 감지는 세 가지 카테고리 중 하나에 속하는 경우가 많습니다:
- 진짜 양성: 순환하고 제거해야 할 합법적인 시크릿. 예:
- 활성 API 키, 데이터베이스 비밀번호, 인증 토큰
- 개인 키 및 인증서
- 서비스 계정 자격증명
- 거짓 양성: 실제 시크릿이 아닌 감지된 패턴. 예:
- 문서의 예제 값
- 테스트 데이터 또는 모의 자격증명
- 자리 표시자 값이 있는 구성 템플릿
- 기록적 발견: 이전에 커밋되었지만 활성 상태가 아닐 수 있는 시크릿. 이러한 감지는:
- 현재 상태를 확인하기 위한 조사가 필요합니다
- 예방 조치로 여전히 순환해야 합니다
유출된 시크릿 수정#
시크릿이 감지되면 즉시 순환해야 합니다. GitLab은 일부 유형의 유출된 시크릿을 자동으로 취소하려고 시도합니다. 자동으로 취소되지 않는 경우 수동으로 수행해야 합니다.
저장소 기록에서 시크릿 제거는 유출을 완전히 해결하지 못합니다. 원래 시크릿은 저장소의 모든 기존 포크 또는 클론에 남아 있습니다.
유출된 시크릿에 응답하는 방법에 대한 지침은 취약점 보고서에서 취약점을 선택하세요.
최적화#
조직 전체에 파이프라인 시크릿 감지를 배포하기 전에 특정 환경에 맞게 거짓 양성을 줄이고 정확도를 향상시키도록 구성을 최적화하세요.
거짓 양성은 경보 피로를 유발하고 도구에 대한 신뢰를 떨어뜨릴 수 있습니다. 사용자 정의 룰셋 구성(Ultimate 전용) 사용을 고려하세요:
- 코드베이스에 특정한 알려진 안전한 패턴을 제외합니다.
- 비시크릿에서 자주 트리거되는 규칙의 민감도를 조정합니다.
- 조직별 시크릿 형식에 대한 사용자 정의 규칙을 추가합니다.
많은 프로젝트가 있는 대규모 저장소나 조직의 성능을 최적화하려면 다음을 검토하세요:
- 스캔 범위 관리:
- 프로젝트에서 기록 스캔을 실행한 후 기록 스캔을 끕니다.
- 사용량이 적은 기간에 기록 스캔을 예약합니다.
- 리소스 할당:
- 대규모 저장소에 충분한 러너 리소스를 할당합니다.
- 보안 스캔 워크로드를 위한 전용 러너를 고려합니다.
- 스캔 기간을 모니터링하고 저장소 크기에 따라 최적화합니다.
최적화 변경 사항 테스트#
조직 전체에 최적화를 적용하기 전에:
- 최적화가 합법적인 시크릿을 놓치지 않는지 검증합니다.
- 거짓 양성 감소 및 스캔 성능 향상을 추적합니다.
- 효과적인 최적화 패턴의 기록을 유지합니다.
도입#
파이프라인 시크릿 감지를 점진적으로 구현해야 합니다. 조직 전체에 기능을 도입하기 전에 소규모 파일럿으로 시작하여 도구의 동작을 이해하세요.
파이프라인 시크릿 감지를 도입할 때 다음 지침을 따르세요:
- 파일럿 프로젝트를 선택합니다. 적합한 프로젝트는 다음과 같습니다:
- 정기적인 커밋을 통한 활발한 개발.
- 관리 가능한 코드베이스 크기.
- GitLab CI/CD에 익숙한 팀.
- 구성을 반복할 의지.
- 간단하게 시작합니다. 파일럿 프로젝트에서 기본 설정으로 파이프라인 시크릿 감지를 활성화합니다.
- 결과를 모니터링합니다. 일반적인 발견 결과를 이해하기 위해 1~2주 동안 분석기를 실행합니다.
- 감지된 시크릿을 처리합니다. 발견된 합법적인 시크릿을 수정합니다.
- 구성을 조정합니다. 초기 결과에 따라 설정을 조정합니다.
- 구현을 문서화합니다. 일반적인 거짓 양성 및 수정 패턴을 기록합니다.
FIPS 지원 이미지#
히스토리
- GitLab 14.10에서 도입되었습니다.
기본 스캐너 이미지는 크기와 유지 관리성을 위해 기본 Alpine 이미지를 기반으로 빌드됩니다. GitLab은 FIPS를 지원하는 Red Hat UBI 버전 이미지를 제공합니다.
FIPS 지원 이미지를 사용하려면 다음 중 하나를 수행하세요:
SECRET_DETECTION_IMAGE_SUFFIXCI/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#
파이프라인 시크릿 감지는 저장소의 기본 브랜치가 작업이 트리거된 브랜치와 관련이 없는 경우 ERR fatal: ambiguous argument 오류로 실패할 수 있습니다. 자세한 내용은 이슈 !352014를 참조하세요.
이 문제를 해결하려면 저장소의 기본 브랜치를 올바르게 설정하세요. secret-detection 작업을 실행하는 브랜치와 관련된 기록이 있는 브랜치로 설정해야 합니다.
작업 로그의 exec /bin/sh: exec format error 메시지#
GitLab 파이프라인 시크릿 감지 분석기는 amd64 CPU 아키텍처에서의 실행만 지원합니다.
이 메시지는 작업이 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는 초기 클론을 위한 러너 변수입니다. 분석기 동작을 변경하지 않습니다.
시크릿 감지 분석기는 다음에 따라 스캔 대상을 결정합니다:
- 파이프라인 유형 (푸시, Merge request, 예약됨)
- 브랜치 컨텍스트 (기본, 새 브랜치, 기존)
- 구성 (
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
이것은 컨테이너화된 환경에서의 일반적인 보안 구성을 나타냅니다. 조치가 필요하지 않습니다.