공개 저장소 API 키 노출: 조사와 대응 순서

2026년 10월 4일 수정. 이전 글은 근거를 제시하지 못한 봇 발견 시간과 긴 공격 경로를 실측 사고처럼 읽히게 했습니다. 그 내용만으로 특정 키에 실제 무슨 일이 있었는지는 알 수 없습니다. 이 글은 공개 저장소에서 확인된 사실과 담당자가 추가로 조사할 사항을 나눠 설명합니다.

공개 저장소에서 확인된 사실

공개 커밋에 자격증명이 들어갔다면 저장소를 읽을 수 있는 사람과 시스템에 노출된 것입니다. 저장소, 커밋, 파일 경로, 최초 확인 시각, 키 종류, 발급처를 기록하세요. 조사 중 키 원문에 접근할 수 있는 사람은 제한합니다. 커밋 작성자는 단서이지만 그 키를 쓰는 서비스의 담당자와 같다고 단정할 수는 없습니다.

노출 사실만으로 키가 아직 작동하는지, 어디에 접근할 수 있는지, 누가 사용했는지는 알 수 없습니다. 가상의 공격 경로를 실제 사고 기록으로 바꾸지 마세요. GitHub는 지원하는 패턴을 검사하지만 탐지와 유효성 확인에는 문서화된 범위가 있습니다. 경고가 없다고 안전한 키라는 뜻은 아닙니다.

유효성·권한·연결 작업 확인

발급처와 해당 키를 쓰는 작업을 찾습니다. 발급처가 안전한 확인 방법을 제공하는 종류라면 현재 유효한지 확인하고, 권한과 접근 범위를 조사합니다. 읽기 전용 API 하나에만 쓰는 키와 관리자 키는 영향이 다릅니다. 만료일, 접근 제한, 같은 값을 공유하는 환경도 기록하세요. 지원되지 않는 키를 임의의 엔드포인트에 시험하지 말고 담당자와 확인합니다.

아직 작동할 가능성이 있는 노출 키는 대응을 조율하는 동안 침해 가능성을 전제로 다룹니다. 연결된 작업의 교체 계획을 세우되 노출된 값이 살아 있는 시간은 줄여야 합니다. 발급처에서 키를 폐기하거나 교체하고 이전 값이 더 이상 통하지 않는지 확인합니다. GitHub는 저장소 기록을 정리하기 전에 먼저 키를 폐기하거나 교체하라고 권합니다.

근거가 있는 사용 흔적 조사

노출 기간에 발급처의 감사 기록과 사용량을 살핍니다. AWS 액세스 키라면 계정의 비인가 활동을 점검하고 CloudTrail 및 관련 서비스 로그를 확인합니다. CloudTrail의 기본 Event history에는 기록 범위와 보존 기간의 한계가 있습니다. 검색 결과가 비어 있어도 사용된 적이 없다고 결론 내리지 말고, 확인한 사실과 로그의 빈틈을 따로 적습니다.

차단 후에는 브랜치, 포크, 빌드 결과물, 배포 파일, 협업 메시지 등 승인된 범위에서 복사본을 찾습니다. 최신 커밋에서 한 줄을 지워도 키가 무효화되거나 과거 복사본이 사라지지는 않습니다. Git 기록을 다시 쓰면 협업자에게 영향이 있으므로 키를 무효화한 뒤 조율해서 진행합니다. 구성 파일 커밋이나 푸시 차단 부재처럼 노출이 일어난 경로도 고칩니다.

Cremit이 도울 수 있는 범위

Cremit Platform은 지원하는 연결 소스에서 자격증명을 찾고, 지원 유형은 발급처에 유효성을 확인하며, 조사 담당자에게 결과를 연결할 수 있습니다. 실제 연결 저장소와 키 종류를 확인한 뒤 검사 범위를 판단해야 합니다. 공격자의 사용 여부를 증명하거나 키를 자동으로 교체하지는 않습니다. 접근 권한과 사용 흔적은 발급처와 그 기록에서 확인해야 합니다.