시크릿 탐지 도구 선택: 검사 범위와 운영 책임

“직접 만들까, 구매할까?”보다 먼저 답할 질문이 있습니다. 자격증명이 어디에 남을 수 있는지, 어떤 확인 결과가 필요한지, 살아 있는 키는 누가 조치할지입니다. GitHub의 기본 기능, 직접 운영하는 검사기, 연결 소스 플랫폼을 함께 쓸 수도 있습니다. 실제 범위는 설정에 따라 달라집니다.

1. 검사할 경계부터 정하기

문제가 GitHub 저장소 안에 있다면 해당 저장소에서 시크릿 스캐닝과 푸시 보호가 사용 가능하고 켜져 있는지 확인하세요. GitHub는 저장소 유형과 플랜별 제공 범위, 지원 패턴과 푸시 보호의 제한을 문서화합니다. 정책에 따라 차단을 우회할 수도 있습니다. 실제 설정을 보고 무해한 테스트 문자열로 동작을 확인해야 합니다.

Gitleaks는 Git 저장소, 디렉터리, 표준 입력을 검사할 수 있습니다. 실행 시점, 커밋 범위, 규칙, 제외 항목, 기준 보고서와 알림 위치를 직접 정합니다. 로컬 훅은 이른 단계에서 변경 내용을 확인할 수 있고 CI는 설정한 범위를 검사합니다. 두 경로 모두 작업과 검사 누락을 관리할 담당자가 필요합니다.

Cremit은 연결한 저장소·클라우드 스토리지·협업 도구 중 지원하는 소스를 검사합니다. 개발자 PC의 모든 Git 훅에서 실행되는 도구는 아닙니다. 저장소를 연결해도 모든 CI 로그나 로컬 파일을 검사했다는 뜻은 아니므로 그 범위는 따로 적어야 합니다.

2. 패턴 발견과 조치 판단 구분하기

패턴 탐지는 발견 위치와 자격증명 후보를 알려 줍니다. 지원하는 유형은 발급처에서 그 시점에 인증되는지 확인할 수 있고, AWS·GCP 연동은 확인 가능한 접근 정보를 더할 수 있습니다. 어느 결과도 공격자가 실제로 키를 썼다는 증거는 아닙니다. 관련 활동 로그를 확인하고 발급처에서 키를 폐기하거나 교체하는 일은 담당자가 진행해야 합니다.

Cremit은 지원하는 유효성·접근 정보와 소스·담당자 단서를 발견 건에 모읍니다. GitHub 저장소에서 푸시 전 차단만 필요하다면 설정한 기본 기능으로 먼저 확인할 수 있습니다. 로컬이나 CI에서 직접 관리할 규칙이 필요하면 Gitleaks를 시험하세요. 여러 연결 소스를 함께 조사하고 발급처 정보를 봐야 한다면 Cremit이 그 소스와 키 유형을 실제로 지원하는지 시험하세요.

3. 실제로 측정할 운영 비용

각 선택지에서 설정·권한 검토, 검사기와 규칙 유지, 제외된 소스, 알림 분류, 발급처 확인, 담당자 전달, 데이터 보관 요건과 라이선스 비용을 기록하세요. “유지비는 개발비의 몇 퍼센트” 같은 공식을 적용하거나 상용 제품이 늘 더 저렴하다고 단정할 근거는 없습니다. 이미 갖춘 통제와 운영하는 소스 수에 따라 답이 달라집니다.

같은 사례로 비교하는 방법

대표 저장소 하나와 검사 권한이 있는 다른 소스 하나를 고릅니다. 무해한 테스트 패턴과 이미 폐기된 과거 사례를 사용하고, 작동하는 키를 시험 삼아 게시하지 마세요. 각 도구가 읽은 소스·커밋 범위, 탐지 패턴, 제외 항목, 유효성·접근 정보 제공 여부, 발견부터 담당자 지정까지 걸린 시간을 적습니다. 도구가 확인할 수 없는 발견 건을 누가 검토할지도 정하세요.

필요한 질문에 답하는 통제를 선택하세요. 검사 결과가 깨끗하다는 것은 설정한 범위에 관한 정보이지 키가 어디에도 없다는 증거는 아닙니다. 실제 키가 공유 소스에 올라갔다면 기록 정리보다 발급처에서의 폐기·교체가 먼저입니다.