Git 시크릿 스캐닝: 설정·한계·대응 가이드 (2026)

2026년 10월 4일 수정. 이전 글은 바이비트 자산 탈취를 Git에 커밋된 개인 키 탓으로 잘못 설명했고, 근거가 불분명한 “저장소 11%” 수치, 오래된 명령어와 고정 가격, 과장된 제품 범위를 실었습니다. 해당 주장을 제거하고 팀이 직접 설정·시험·확인할 수 있는 절차로 다시 썼습니다.

Git 시크릿 스캐닝이란?

Git 시크릿 스캐닝은 소스 파일과 커밋 기록에서 자격증명이나 그와 닮은 값을 찾습니다. 보통 발급처별 패턴이나 일반 패턴을 씁니다. 패턴에 걸렸다는 사실만으로 발급처에서 아직 작동하는지, 어디에 접근하는지, 누가 악용했는지 알 수는 없습니다. 지원하고 설정된 발급처 유효성 검사는 그중 현재 상태에 관한 더 좁은 질문에 답합니다.

도구를 고르기 전에 범위를 정하세요. 저장소, 브랜치, 과거 커밋, PR, 이슈, 위키, CI 산출물, 협업 도구 중 무엇을 검사해야 하나요? GitHub는 브랜치별 Git 기록과 일부 호스팅 텍스트의 검사 범위를 문서화합니다. GitLab은 푸시 보호, 파이프라인 탐지, 입력 시 탐지를 나눠 설명합니다. 설정과 범위가 다릅니다. 로컬 Git 검사 결과를 호스팅 이슈나 Slack 메시지까지 검사한 결과로 해석해서는 안 됩니다.

세 지점에서 검사를 설정합니다

1. 푸시하기 전

지원하는 경우 호스팅 서비스의 푸시 보호를 켜고 어떤 키 종류를 차단하는지 확인합니다. GitHub에 따르면 푸시 보호는 식별이 쉬운 일부 패턴에 적용되며 크거나 복잡한 푸시는 건너뛰거나 시간 초과될 수 있습니다. GitLab 푸시 보호는 허용된 우회를 사용하지 않는 한 푸시를 막을 수 있습니다. 로컬 훅도 도움이 되지만 구성원마다 설치 여부와 우회 기록을 확인해야 합니다.

2. 푸시 또는 머지 요청 이후

저장소 또는 파이프라인 경고를 켜고 경고를 받을 담당자를 정합니다. GitHub에서는 요금제와 저장소 설정에 따른 기능 및 지원 패턴을 확인하세요. GitLab에서는 기본 브랜치뿐 아니라 머지 요청 파이프라인에서도 탐지가 실행되는지 살핍니다. 실제로 쓸 수 없는 시험 값을 비공개 시험 저장소에 넣어 설정한 규칙과 경고 전달을 검증합니다. 작동하는 키를 시험용으로 게시하지 마세요.

3. 기존 Git 기록과 로컬 파일

새 보호 장치보다 오래된 저장소는 과거 기록도 검사합니다. 현재 Gitleaks에서 “gitleaks git .”은 로컬 Git 패치를, “gitleaks dir .”은 디렉터리 파일을 검사합니다. 예전 “detect”, “protect” 명령은 더 이상 권장되지 않습니다. 다른 참조나 특정 커밋 구간까지 보려면 Git 로그 옵션을 설정해야 합니다. 기준 보고서로 오래된 결과와 새 경고를 나눌 수 있지만, 살아 있는 키를 그대로 둘 근거는 아닙니다.

발견, 유효성, 권한, 악용을 구분합니다

정확한 발견 위치와 그곳을 읽을 수 있던 대상을 기록합니다. 실제 자격증명 형식인지 시험 값인지 구분합니다. 지원하는 안전한 방법이 있을 때만 발급처에 현재 유효성을 확인하고, 확인할 수 없으면 “알 수 없음”으로 두고 발급처나 담당자에게 묻습니다. 발급처에서 계정, 권한, 만료일, 사용하는 작업을 찾습니다. 마지막으로 가능한 활동 로그에서 수상한 사용을 조사합니다. 발견·유효·고권한·악용은 각각 다른 결론입니다.

제품 이름만으로 검사 범위를 추측할 수 없습니다. GitHub 문서에 따르면 AWS 액세스 키 ID와 비밀값 같은 쌍 패턴은 두 부분이 같은 파일과 저장소에 있어야 탐지됩니다. 푸시 보호도 일부 패턴과 버전에만 적용됩니다. 경고가 없다는 것은 설정한 소스와 탐지 규칙의 결과이지, 다른 곳에도 자격증명이 없다는 증거는 아닙니다.

발급처에서 먼저 접근을 닫습니다

노출된 키가 살아 있을 가능성이 있다면 서비스 담당자가 새 키를 준비하고 발급처에서 기존 값을 폐기하거나 교체합니다. 종속 작업이 정상이고 이전 값이 통하지 않는지 확인합니다. 발급처 로그를 실제 수집 범위에서 검토합니다. 노출 복사본과 유출 경로도 정리합니다. GitHub는 저장소 기록을 다시 쓰기 전에 키를 먼저 폐기하거나 교체하라고 안내합니다. 기록 수정은 커밋 해시를 바꾸며 다른 사람의 복제본까지 지울 수 없습니다. 담당자, 조치, 시각, 남은 의문을 기록합니다.

도구는 같은 시험으로 비교합니다

GitHub 저장소에는 GitHub 자체 검사가 출발점이고 GitLab 작업에는 GitLab의 보호 장치가 있습니다. Gitleaks는 로컬 Git 및 파일 검사를 구성할 수 있습니다. 현재 문서를 읽고, 필요한 소스와 단계에 작동하지 않는 동일한 시험 값을 넣어 보세요. 지원 패턴, 과거 기록, 경고 전달, 유효성 검사, 연결 권한, 사람이 조치하는 흐름을 비교합니다. 오래된 글의 고정 탐지 규칙 수나 가격은 선택 기준으로 쓰지 않습니다.

Cremit Platform은 지원하는 연결 GitHub·GitLab·Bitbucket 저장소와 설정된 GitHub Packages, S3, Google Drive, Slack, Jira, Confluence, Notion에서 자격증명을 찾습니다. 발견 위치를 기록하고 지원 유형은 발급처에 확인하며 AWS 액세스 키와 GCP API 키에는 제공 가능한 권한 정보를 붙입니다. 팀은 담당자를 지정해 조치를 추적할 수 있습니다. 모든 소스를 검사하거나 악용을 입증하거나 키를 자동 교체·폐기하지는 않습니다. Git 호스트의 푸시 차단과 연결 소스의 발견 결과는 서로 다른 질문에 답합니다.

도입 체크리스트

소스와 담당자를 적고, 호스팅 서비스와 요금제가 지원하는 보호 장치를 켭니다. 기존 기록을 검사하고, 작동하지 않는 시험 값 한 건으로 발견부터 경고·조치까지 확인합니다. 발급처 유효성 확인과 폐기를 맡을 사람을 정합니다. 미검토, 유효성 불명, 활성 확인, 폐기 완료, 오탐을 따로 기록합니다. 새 저장소·키 형식·협업 도구가 생기면 검사 범위를 다시 봅니다.