깃허브에 올린 키, 아직 살아 있을 수 있다 | 작동하는 키 54만 개 조사로 본 내 저장소 점검법

예전에 연습용으로 만든 깃허브 저장소에 API 키를 그대로 올렸다가 "어차피 아무도 안 보겠지" 하고 넘어간 적이 있다면, 그 키는 지금도 작동하고 있을 수 있습니다.

보안업체 트러플 시큐리티(Truffle Security)가 9월 29일 공개한 조사에 따르면, 공개 깃허브 저장소에서 찾은 키·접속 정보 같은 자격증명 가운데 543,699개가 2026년 7월에도 실제로 작동했습니다. 제미나이 API 키만 31,374개입니다. 왜 이렇게 오래 살아남는지, 깃허브의 푸시 보호가 무엇을 놓치는지, 내 저장소를 점검하고 키를 바꾸는 순서를 정리했습니다.

트러플 시큐리티는 AI 학습용으로 모은 공개 깃허브 저장소 스냅샷(The Stack v3, 2억 2,455만 개 저장소, 2025년 8월 수집 마감)을 조사해 2026년 7월 27~28일 검증 당시 작동한 자격증명 543,699개를 찾았다. 파일 수정 시각 기준 추정 노출 기간 중앙값은 784일이고, 199,843개는 깃허브가 2024년 2월 푸시 보호를 기본으로 켠 뒤 수정된 파일에서 나왔다. 살아 있는 키의 51.8%는 DB 접속 문자열, 구글 API 키, 개인 키처럼 푸시 보호가 기본으로 막지 않는 형태였고, 제미나이 키는 31,374개였다. npm·깃허브 토큰은 발급사의 자동 폐기 덕분에 거의 살아남지 않았다. 이 수치는 특정 시점 스냅샷이며 실제로 악용됐다는 뜻은 아니다. 키가 새었다면 저장소 정리보다 키 폐기·재발급이 먼저다.

목차

1. 543,699개, 무엇을 조사한 숫자인가

2. 푸시 보호가 있는데 왜 살아 있나

3. 내 저장소 점검하기

4. 키가 새어 나갔다면: 순서가 중요하다

1. 543,699개, 무엇을 조사한 숫자인가

트러플 시큐리티 조사는 AI 모델 학습용으로 모은 공개 깃허브 스냅샷 "The Stack v3"를 대상으로 했습니다. 저장소 2억 2,455만 개, 파일 584억 개입니다. 여기서 찾은 키 후보를 2026년 7월 27~28일 실제 발급 서비스에 넣어 보고, 작동한 것만 셌습니다.

출처: Truffle Security 보고서 갈무리

항목	수치
작동한 자격증명	543,699개 (노출 위치 1,103,438곳)
추정 노출 기간 중앙값(파일 수정 시각 기준)	784일
가장 오래된 자격증명	파일 최종 수정 2009년 6월, 16.1년째 작동
푸시 보호 기본 적용(2024.2) 이후 수정된 파일에서 나온 것	199,843개
제미나이 API 키	31,374개 (노출 시점 중앙값 2025년 2월)

출처: Truffle Security 보고서 갈무리

핵심 이 숫자는 키가 "작동한다"는 뜻이지 "누군가 악용했다"는 뜻이 아닙니다. 기본 브랜치만 본 스냅샷이라 삭제되거나 강제 푸시로 지워진 키는 빠져 있고, 트러플은 실제 규모가 더 클 것이라고 봤습니다.

2. 푸시 보호가 있는데 왜 살아 있나

깃허브는 2024년 2월 29일부터 공개 저장소에 알려진 형태의 비밀값을 푸시하면 막는 "푸시 보호"를 기본으로 켰습니다. 트러플 분석으로는 이 장치가 적용되는 키의 유출 속도를 약 절반으로 줄였습니다. 문제는 적용되지 않는 키입니다.

종류	작동 중인 수	푸시 보호 기본 차단
구글 클라우드 서비스 계정	69,041개	차단
MongoDB 접속 문자열	51,067개	기본 미차단
구글 API 키(제미나이 검증)	33,343개	기본 미차단
Postgres 접속 문자열	11,465개 / 12,985개	기본 미차단
npm 토큰	1개 / 101,886개	차단, 발급사 자동 폐기
깃허브 토큰	260개 / 73,048개	차단, 자동 폐기

출처: Truffle Security 보고서 갈무리

구글 API 키가 막히지 않는 이유도 보고서에 나옵니다. 지도용 키는 원래 웹 페이지에 넣어 쓰는 공개 키라서, 같은 "AIzaSy"로 시작하는 제미나이 키와 형태로는 구분이 안 됩니다. 깃허브 지원 패턴 목록에서도 제미나이 키는 푸시 보호 대상이 아닌 것으로 표시돼 있습니다.

주의 제미나이 키는 유료 사용이 켜져 있다면 남이 쓴 만큼 요금이 나갈 수 있습니다. 공개 저장소나 프런트엔드 코드에 들어 있다면 지금 바로 사용량과 결제 내역부터 확인하세요.

3. 내 저장소 점검하기

푸시 보호는 앞으로 올라오는 키만 검사합니다. 이미 올라간 키, 특히 2024년 2월 이전 커밋은 직접 찾아야 합니다. 방법은 세 가지입니다.

도구	하는 일	비용
깃허브 시크릿 스캐닝	저장소 Settings의 보안 메뉴(Advanced Security > Secret Protection)에서 켜고 알림 확인. 히스토리도 검사	공개 저장소 무료
trufflehog	히스토리를 훑고 발급사에 물어 "작동하는 키"만 표시	오픈소스
gitleaks	규칙 기반으로 빠르게 검사, 커밋 전 훅으로도 사용	오픈소스

내 컴퓨터에서 점검 (저장소 폴더 안에서)

brew install trufflehog gitleaks

# 작동하는 키만 표시
trufflehog git file://. --only-verified

# 규칙 기반 전체 검사
gitleaks git -v

재구성한 예시 화면

설치·명령 형식은 trufflehog와 gitleaks 공식 저장소 기준이며 버전에 따라 조금 다를 수 있습니다. 결과에 나온 값은 화면을 캡처해 공유하지 말고, 어떤 서비스의 키인지만 확인한 뒤 바로 다음 단계로 넘어가세요.

4. 키가 새어 나갔다면: 순서가 중요하다

반응형

순서	할 일	이유
1	발급처 콘솔에서 키 폐기·재발급	저장소를 지워도 복제본과 포크에는 남는다
2	사용량·결제·접속 기록 확인	이미 쓰였는지 판단
3	새 키는 .env에 두고 .gitignore에 추가	같은 실수 방지
4	필요하면 히스토리 정리(git filter-repo 등)	키를 끈 다음에야 의미가 있다
5	만료 기간과 최소 권한 설정, 제미나이 키는 API 제한	다음 유출 때 피해를 줄인다

트러플의 권고도 같습니다. 커밋된 순간 그 키는 "탄 것"으로 보고, 먼저 교체하고 정리는 그다음에 하라는 것입니다. npm·깃허브 토큰은 발급사가 자동으로 폐기해 거의 살아남지 않았지만, 아무도 끄지 않는 DB 접속 문자열은 대부분 살아 있었습니다. 결국 키를 끄는 사람이 있어야 끝납니다.

Q. 저장소를 비공개로 바꾸면 해결되나요?

아닙니다. 이미 다른 사람이 복제했거나 이번처럼 스냅샷에 담겼을 수 있습니다. 키를 폐기하고 새로 발급받는 것이 먼저입니다.

Q. 푸시 보호가 켜져 있으면 안전한가요?

지원하는 형태의 토큰은 막지만 전부는 아닙니다. 트러플 조사에서 살아 있는 키의 51.8%는 DB 접속 문자열, 구글 API 키, 개인 키처럼 기본으로 막히지 않는 형태였습니다.

Q. 이 조사에서 제 키가 나왔는지 알 수 있나요?

트러플은 저장소 이름을 공개하지 않았습니다. trufflehog나 깃허브 시크릿 스캐닝으로 직접 점검해야 합니다.

Q. 키가 작동했다면 이미 해킹당한 건가요?

그렇지는 않습니다. 이번 수치는 작동 여부만 확인한 스냅샷입니다. 실제 악용 여부는 사용 기록과 결제 내역으로 확인해야 합니다.

3줄 핵심 요약

1. 공개 깃허브에서 찾은 자격증명 543,699개가 2026년 7월에도 작동했다. 제미나이 키만 31,374개다.
2. 푸시 보호는 지원 패턴의 토큰을 막지만, DB 접속 문자열·구글 API 키는 기본으로 통과한다.
3. trufflehog·gitleaks·시크릿 스캐닝으로 점검하고, 찾으면 저장소 정리보다 키 폐기가 먼저다.

마치며

오늘 공개 저장소 하나를 골라 trufflehog git file://. --only-verified를 한 번 돌려 보세요. 아무것도 안 나오면 다행이고, 무언가 나오면 그 키를 지금 끄는 것이 오늘 할 일의 전부입니다.

NEXT READ

이어서 읽어 볼 글

01  받은 저장소를 AI 에이전트로 열기 전에 · 저장소 보안 하나 더

02  코딩 에이전트에게 권한을 얼마나 줄까 · 에이전트와 비밀값

#깃허브,#GitHub,#API키,#시크릿유출,#제미나이API,#trufflehog,#gitleaks,#보안,#개발자,#코드노트