대상: GitHub 같은 공개 저장소에 코드를 두는 개발자, 그리고 API를 운영하는 회사. 이 글은 한 보안 회사의 연구에 나온 숫자를 이 사이트의 말로 다시 정리한 것입니다. 다른 사람의 인증 정보를 찾는 방법은 다루지 않습니다.
이 연구는 무엇인가 (GitHub의 공식 연구가 아니다)
2026년 9월 29일, 비밀값 검사 도구를 판매하는 보안 회사 Truffle Security가 공개 저장소에 남은 인증 정보에 관한 연구를 공개했습니다. 탐지 도구 판매사인 만큼, 공개한 쪽은 이 주제에 상업적 이해관계가 있습니다. 이 글은 연구의 숫자를 보고된 그대로 쓰고, 이 사이트의 해석은 따로 구분해 적습니다.
GitHub가 무언가를 유출한 것은 아닙니다. 인증 정보는 각 저장소의 소유자가 코드에 적어 공개한 것입니다. GitHub의 역할은 push protection(비밀값이 포함된 push를 막는 기능) 같은 예방 기능을 제공하는 것이며, 아래에서 보듯이 그 기능이 다루는 유형은 한정돼 있습니다.
연구 방법과 숫자를 읽는 법
- 원본 데이터는 The Stack v3로, 제3자가 LLM(대규모 언어 모델) 학습용으로 수집한 공개 저장소 데이터셋입니다. 수집은 2025년 8월 7일에 마감됐습니다.
- 수집 시점의 기본 브랜치(main 등)만 조사했습니다. 이전 커밋, 다른 브랜치, 그전에 삭제된 것은 포함되지 않습니다. GitHub의 모든 공개 코드를 검사한 것이 아닙니다.
- '유효'는 2026년 7월 27~28일에 제공자가 그 인증 정보로 여전히 인증된다고 확인했다는 뜻입니다. 그 뒤에 폐기된 것도 있을 수 있습니다.
- 노출 후 경과 기간은 인증 정보가 들어 있는 파일의 마지막 수정일부터 셉니다. 연구는 이 방식이 실제 기간을 짧게 잡는 경향이 있다고 밝힙니다.
- 일부 유형은 특정 수치에서 빠져 있습니다. Google API 키는 Gemini에 대해서만 시험했고, 개인 키는 해당 호스트 없이는 시험할 수 없기 때문에, 둘 다 유형별 생존 수치에 포함되지 않습니다.
숫자: 무엇이 얼마나 남아 있었나
2024년 2월 29일이 있는 주에 GitHub는 모든 사용자의 공개 저장소 push에 대해 push protection을 기본으로 켜기 시작했습니다. 연구에 따르면 유효한 인증 정보 543,699건 중 199,843건(36.8%)은 그날 이후에 나타났습니다.
또 유효한 인증 정보의 51.8%는 연결 문자열, Google API 키, 개인 키로, push protection이 기본으로 막지 않는 유형이었습니다. push protection이 다루는 유형은 변경 전후 12개월을 비교했을 때 파일 100만 개당 유출 건수가 약 53% 줄었습니다. 다루지 않는 유형은 약 7% 줄어드는 데 그쳤습니다. 연구 자신도 같은 기간에 클라우드 제공자들이 고객에게 단기 인증 정보를 권한 것 같은 다른 요인이 섞여 있을 수 있다고 밝힙니다.
유형별로 얼마나 살아 있었나
아래 표는 연구가 공개한 건수로 비율을 다시 계산한 것입니다. '발견'은 기본 브랜치에서 찾은 인증 정보 수, '유효'는 그중 확인 시점에 여전히 인증된 수입니다.
| 유형 | 발견 | 유효 | 유효 비율 |
|---|---|---|---|
| npm 토큰 | 101,886 | 1 | 0.001% |
| Hugging Face 토큰 | 30,437 | 15 | 0.05% |
| GitHub 토큰 | 73,048 | 260 | 0.4% |
| Slack 토큰 | 8,903 | 198 | 2.2% |
| Stripe 키 (테스트 모드 키 포함) | 124,132 | 4,493 | 3.6% |
| AWS 액세스 키 | 82,411 | 6,819 | 8.3% |
| Docker Hub 토큰 | 3,790 | 1,244 | 32.8% |
| SendGrid 키 | 22,800 | 9,189 | 40.3% |
| Google Cloud 서비스 계정 키 | 126,963 | 69,041 | 54.4% |
| MySQL 연결 문자열 | 2,421 | 1,806 | 74.6% |
| PostgreSQL 연결 문자열 | 12,985 | 11,465 | 88.3% |
| MongoDB 연결 문자열 | 집계 안 됨 | 51,067 | — |
MongoDB에 쓰인 탐지기는 연결에 성공한 문자열만 기록하기 때문에 비율을 계산할 수 없어 생존 수치에서 빠져 있습니다. 유효 건수만 보고됐습니다.
유형마다 차이가 큰 이유
차이는 인증 정보를 찾기 쉬운지보다, 찾은 뒤에 누군가 그것을 멈추는지에서 생깁니다. 각 제공자의 공식 문서로 확인할 수 있었던 범위에서는 다음과 같습니다.
발급자가 자동으로 멈춘다
- GitHub 토큰: 공개 저장소나 gist에 push된 유효한 토큰은 자동으로 폐기된다고 GitHub가 문서에 밝힘
- npm 토큰: 2019년부터 npm이 GitHub에서 발견된 유효한 토큰을 폐기하고 소유자에게 메일로 알림
- Hugging Face: 소유자뿐 아니라 누구나 유출된 토큰을 무효화할 수 있는 공식 방법이 있음
나만 멈출 수 있다
- 데이터베이스 연결 문자열: 발급자가 없으며, 비밀번호를 바꿀 때까지 작동함
- 많은 API 키: GitHub가 통지한 뒤 무엇을 할지는 발급자에게 달림
- 내 서버의 개인 키: 어디에 쓰이는지는 소유자만 앎
GitHub의 secret scanning 파트너 프로그램은 공개 저장소에서 발견된 인증 정보를 발급자에게 알립니다. GitHub 문서는 통지된 비밀값을 공개되고 침해된 것으로 취급하라고 권하지만, 구현은 발급자에게 맡깁니다. 폐기할지, 재발급할지, 사용자에게 연락할지는 발급자가 정합니다.
두 클라우드 제공자의 대응은 완전한 폐기와 같지 않습니다.
- AWS: 액세스 키가 노출됐을 수 있는 IAM 사용자에게 "AWSCompromisedKeyQuarantineV3"라는 관리형 정책을 붙입니다. 인스턴스 실행이나 IAM 변경 같은 특정 작업을 거부하지만, 키를 삭제하지는 않습니다. AWS는 고객에게 이 정책을 제거하지 말고, AWS가 여는 지원 케이스의 안내를 따르라고 요청합니다.
- Google Cloud: 2024년 6월 16일부터 공개 저장소 등에서 탐지된 서비스 계정 키를 기본적으로 자동 비활성화합니다. 조직은 조직 정책 제약 조건
iam.serviceAccountKeyExposureResponse로 이를 끌 수 있습니다(WAIT_FOR_ABUSE). 그런데도 연구에서는 절반 이상이 유효했으며, 연구는 그 이유를 설명하지 않습니다.
이 사이트의 시각: 지워도 다른 곳에 사본이 남는다
이 연구 자체가 2025년 8월에 만든 데이터셋을 썼습니다. 소유자가 그 뒤에 파일을 지웠더라도 인증 정보는 데이터셋에 남아 있습니다. 포크, 다른 사람의 클론, 미러, 검색이나 AI 학습 데이터도 마찬가지입니다.
그러니 "공개 저장소에 push했다"는 "유출됐다"로 취급하고, 발급자 쪽에서 인증 정보를 무효화하세요. 이력 재작성은 더 퍼지지 않게 하는 정리 작업입니다.
내 저장소
삭제 또는 이력 재작성
포크, 클론, 미러
다른 사람의 기기에 있음
데이터셋, 아카이브
수집 시점의 사본
발급자가 폐기
모든 사본이 작동하지 않게 됨
유출한 것을 발견했다면
발급자 쪽에서 키를 폐기한다
사용 내역과 요금을 확인한다
새 키를 발급해 교체한다
이력 정리는 마지막에 한다
다른 사람의 키를 발견했다면 시험하지 않는다
다른 사람의 저장소에서 인증 정보를 발견했다면 작동하는지 확인하지 마세요. 소유자나 발급자에게 알리세요. GitHub 공개 저장소의 지원 유형이라면 GitHub가 발급자에게 알립니다.
유출 예방
push protection은 도움이 되지만 그것만으로는 부족합니다. 숫자에서 보듯 기본으로 막지 않는 유형은 그대로 통과하고, 사용자는 이유를 골라 차단을 우회할 수 있습니다. 다음과 함께 쓰세요.
- 커밋 전에 검사한다: gitleaks 같은 검사 도구로 push 전에 내 기기에서 비밀값을 막습니다(gitleaks로 커밋 전 비밀값 검사 참고).
- 오래된 저장소의 이력을 검사한다: push protection은 켜기 전에 만든 커밋에는 아무 효과가 없습니다. 방치된 저장소와 보관 처리된 저장소의 전체 이력을 적어도 한 번은 검사하세요.
- 단기 인증 정보를 쓴다: GitHub Actions는 장기 키를 저장하지 않고 OIDC(실행할 때마다 짧은 시간만 유효한 인증 정보를 받는 방식)로 AWS나 Google Cloud에 연결할 수 있습니다. Hugging Face도 같은 방식을 제공합니다.
- 키마다 할 수 있는 일을 좁힌다: 읽기 전용, 특정 API만, 접속 IP나 리퍼러 제한, 유효 기간. 유출됐을 때의 피해를 제한합니다.
- 데이터베이스를 인터넷에 노출하지 않는다: 유출된 연결 문자열도 외부에서 접속할 수 없다면 쓸모가 없습니다. 표에서 가장 오래 살아남은 유형이 데이터베이스 연결 문자열이었습니다.
코드에 비밀값을 남기지 않는 기본은 .env와 API 키는 무엇이 실제로 위험한가에, 웹 서버에 남은 비밀값은 공개 디렉터리 점검에서 다룹니다.
API를 운영하는 회사를 위해
표의 위쪽과 아래쪽을 가른 것은 발급자가 유출된 키를 자동으로 멈추는가였습니다. 사용자의 키를 지키는 쪽으로서 다음을 검토하세요.
- GitHub의 secret scanning 파트너 프로그램에 참여하고, 통지를 받으면 유효한 키를 폐기하고 사용자에게 알리기
- 키에 특징적인 접두사(예: 서비스 이름으로 시작하는 것)를 붙여 탐지하기 쉽게 하기
- 누구나 유출된 키를 신고하고 무효화할 수 있는 창구나 API 제공하기
- 유효 기간이 있는 키와 범위를 좁힌 키를 기본값으로 하기
출처 (공개 기록)
이 글의 숫자는 아래 공개 자료를 따릅니다. 연구의 본문이나 도표를 옮기지 않았으며, 건수만 써서 다시 정리했습니다.
- Truffle Security(비밀값 검사 도구 제공 업체)의 연구, 2026년 9월 29일 — trufflesecurity.com
- 보도: BleepingComputer(2026년 9월 30일) ／ SecurityWeek(2026년 10월 1일) ／ GIGAZINE(2026년 10월 2일, 일본어)
- GitHub: push protection 기본 적용(GitHub Blog) ／ About push protection ／ 지원 패턴 ／ 파트너 프로그램 ／ 토큰 만료와 폐기
- npm: npm Blog(2019년 6월 18일)
- Hugging Face: User access tokens(유출된 토큰 폐기)
- AWS: AWSCompromisedKeyQuarantineV3
- Google Cloud: 유출된 서비스 계정 키 자동 비활성화(2024년 5월 16일) ／ 서비스 계정 키 관리 모범 사례
다음에 읽을 글
- GitHub 설정: GitHub 2단계 인증 설정 방법
- 예방: gitleaks로 커밋 전 비밀값 검사 ／ 비밀값 유출 검사기(붙여 넣어 검사)
- 기초: .env와 API 키는 무엇이 실제로 위험한가 ／ .env 파일이란
- 유출의 대가: AI가 쓴 코드가 API 키를 유출해 부정 청구가 발생한 사례
- 개발자 인증 정보를 노리는 공격: 공급망 웜 방어 ／ TanStack, Nx Console, GitHub로 이어진 침해 연쇄(2026년 5월)
- 키 권한 좁히기: SSH 키 최소 권한
FAQ
QGitHub의 공식 연구인가요?
아닙니다. 비밀값 검사 도구를 제공하는 보안 회사 Truffle Security가 2026년 9월 29일에 공개한 연구입니다. GitHub가 무언가를 유출한 것이 아니라, 인증 정보는 각 저장소의 소유자가 코드에 적어 공개한 것입니다. GitHub는 push protection과 secret scanning 같은 예방 기능을 제공하지만, 대상 인증 정보 유형은 한정돼 있습니다.
QAPI 키를 커밋했습니다. 파일을 지우거나 이력을 다시 쓰면 충분한가요?
공개 저장소에 push한 순간, 포크, 다른 사람의 클론, 미러, 그리고 이번 연구에 쓰인 것 같은 데이터셋에 사본이 이미 있을 수 있습니다. 파일 삭제나 이력 재작성으로는 그 사본이 사라지지 않습니다. 첫 단계는 발급자 쪽에서 키를 폐기하고 새 키를 발급하는 것입니다. 이력 정리는 그다음입니다.
Q유출된 키는 발급자가 자동으로 폐기해 주지 않나요?
발급자에 따라 다릅니다. GitHub 문서에 따르면 공개 저장소에 push된 유효한 GitHub 토큰은 자동으로 폐기되며, npm도 2019년부터 자사 토큰에 같은 조치를 하고 있습니다. 하지만 GitHub의 secret scanning 파트너 프로그램에서 통지를 받은 뒤 무엇을 할지는 발급자에게 맡겨져 있습니다. 데이터베이스 연결 문자열처럼 뒤에 발급자가 없는 인증 정보는 아무도 멈춰 주지 않습니다.
QGitHub push protection으로 막을 수 있나요?
일부만 막습니다. push protection은 기본적으로 지원 패턴 목록에 있는 특정 토큰 형식을 막습니다. GitHub의 패턴 목록에는 Google API 키와 MongoDB, PostgreSQL 연결 문자열이 push protection 없이 경고만 하는 유형으로 나와 있습니다. 사용자가 이유를 골라 차단을 우회하거나 기능을 끌 수도 있습니다. 커밋 전 검사와 단기 인증 정보를 함께 쓰세요.
Q연구에서 '유효(live)'는 무슨 뜻인가요?
연구는 패턴으로 인증 정보를 찾은 뒤, 2026년 7월 27~28일에 각 제공자에게 그 인증 정보로 여전히 인증되는지 확인했습니다. 어떤 권한을 갖고 있었는지, 악용됐는지는 확인하지 않았습니다. 그 뒤에 폐기된 것도 있을 수 있습니다.