클로드 코드 비밀번호 노출, 공개 GitHub 1,122개 파일에서 실제 키 1,379개

클로드 코드(Claude Code) 비밀번호 노출은 설정 파일 하나에서 시작된다. 승인 창에서 "다시 묻지 않기"를 누르면 그때 실행한 명령어가 프로젝트 폴더의 .claude/settings.local.json 에 그대로 저장된다. 명령어에 데이터베이스 비밀번호가 들어 있었다면 비밀번호도 같은 줄에 남는다. 보안 업체 아피로(Apiiro)가 공개 GitHub에서 이 파일 104,185개를 내려받아 확인한 결과, 그중 1,122개에 실제 형식의 비밀 1,379개가 들어 있었다.

아피로가 11월 5일 공개한 연구다. 수집은 11월 1~3일 읽기 전용 코드·커밋 검색으로 했고, 어떤 자격 증명도 실제로 사용하거나 호스트에 접속하지 않았다. 확인된 파일은 전부 11월 2일 기준 각 저장소의 기본 브랜치에 그대로 있었다.

클로드 코드 비밀번호 노출은 어떻게 일어나나 — 승인한 명령이 파일에 남는다

개발자 노트북에는 접속 정보가 있다. 스테이징 로그인이 왜 안 되는지 확인해 달라거나 마이그레이션을 돌려 달라고 하면, 에이전트가 제안하는 명령에는 그 정보가 들어간다. 없으면 명령이 실행되지 않기 때문이다. 클로드 코드는 기본 설정에서 셸 명령을 실행하기 전에 승인을 요구한다. 자동 모드를 켜 두면 묻지 않는다. 여기서 "Yes, and don't ask again" 을 고르면 명령 문자열 자체가 권한 규칙으로 저장된다.

문제는 그 파일이 저장소 안에 있다는 점이다. 클로드 코드가 파일을 직접 만들면 개발자의 전역 gitignore 에 넣는다. 하지만 나중에 저장소가 되는 폴더, 다른 기기에서 복제한 사본, 이미 누군가 커밋한 파일은 이 보호 밖이다. 저장소 자체의 .gitignore 에는 규칙이 들어가지 않아 프로젝트와 함께 따라가지 않는다.

아피로는 이 동작이 모델 탓이 아니라고 적었다. Opus 5.5 와 Fable 5.1 에서도 재현됐다. 비밀이 든 파일을 추적한 저장소 1,105곳 가운데 539곳에서는 클로드가 공동 작성자로 이름을 올린 커밋이 그 파일을 바꿨다. Sonnet 4.5 부터 Opus 5.5 까지 여러 모델이 등장한다.

규모 — 공개 파일 1,122개, 비밀 1,379개

공개 GitHub의 .claude/settings.local.json 은 103,617개 저장소에 104,185개가 있다. 이 중 1.1%인 1,122개가 실제 비밀이었다. 값으로 세면 1,379개이며, 제공자 형식의 키 636개와 공개 호스트용 비밀번호·토큰 743개로 나뉜다.

나머지는 서드파티 서비스와 AI 모델 API 토큰이다. 세 번째 줄의 Supabase 계정 토큰은 계정 안의 모든 프로젝트를 제어한다. 첫 줄의 데이터베이스 비밀번호 379개는 원격에서 DB에 바로 붙을 수 있는 값이다.

노출된 조직은 63곳이다. 데이터베이스 업체가 자기 클라우드 API 키(관리 권한·만료 없음)와 클러스터 호스트를, B2B 스타트업이 운영 Azure Postgres 비밀번호를, 소프트웨어 에이전시가 Square 운영 토큰을 공개했다. 의료 기록 앱을 만드는 IT 서비스 회사의 클라우드 DB 소유자 비밀번호도 이 목록에 있었다. 아피로는 11월 2~3일 각 조직에 알렸고, 한 곳은 키가 실제로 살아 있었다고 확인했다.

오래된 것도 많다. 비밀이 든 파일이 처음 커밋된 시점은 중앙값 217일 전이고, 118개 저장소는 1년을 넘겼다. 74개 저장소의 포크 211개가 같은 비밀을 복사해 갖고 있다. 파일을 지워도 끝나지 않는다. 현재 사본에는 없는 비밀 734개가 509개 저장소의 과거 커밋에 남아 있다.

git 기록과 공유 설정, 저장소에 딸린 대화 기록까지 넣으면 1,994개 저장소에 2,539개다. 아피로는 "GitHub는 우리가 셀 수 있었던 곳일 뿐"이라며, 같은 파일이 "다시 묻지 않기"를 누른 모든 노트북에 평문으로 있다고 적었다.

gitleaks·TruffleHog도 놓친 215개 — 비밀번호가 명령줄 안에 있다

아피로는 104,185개 파일 전체에 gitleaks 와 TruffleHog 를 돌렸다. gitleaks 는 1,122개 중 564개, TruffleHog 는 643개를 잡았다. 둘 다 놓친 파일이 215개다. 다섯 중 하나꼴로 스캐너를 그냥 지나간 셈이다.

이유는 형식이다. 스캐너는 제공자 접두사가 붙은 키를 찾는다. PGPASSWORD= 뒤에 온 비밀번호, sshpass -p 로 넘긴 암호, mysql -p 에 이어 붙인 값, curl 헤더의 bearer 토큰은 평범한 명령줄의 평범한 단어다. 이 패턴은 이 파일에만 있지 않다. 에이전트가 실행 기록·메모리 파일·핸드오프 노트에 남기는 곳마다 같은 구멍이 생긴다.

허용 목록이 길수록 위험하다. 8KB가 넘는 파일은 10개 중 1개가 실제 비밀이었고, 500바이트 미만은 500개 중 1개 미만이었다. "다시 묻지 않기"를 오래 눌러온 사람의 파일일수록 크고 위험하다.

다른 파일도 같은 식으로 샌다. 팀이 공유하려고 커밋하는 settings.json 76,011개 중 298개, 저장소에 딸린 에이전트 대화 기록 2,523개 중 120개(87개 저장소), MEMORY.md 류 메모는 1,200개 중 9곳, 핸드오프·배포 노트는 2,095개 중 33개, VS Code Copilot 자동 승인 설정은 173개 중 9곳이었다. 허깅페이스 스페이스 31,053개 중 126개가 같은 파일을 갖고 있었고, 그중 하나에는 DB 서비스 키와 사용자 비밀번호가 함께 들어 있었다. GitLab.com 의 공개 사본 69개 중 2개도 실제 비밀이었다.

원문 반응 — "헤드라인이 과하다"와 "그래도 위험하다"

해커뉴스에서 이 글은 240점을 받고 댓글 148개가 붙었다. 제목을 문제 삼는 댓글도 있었다. 한 이용자는 "'다시 묻지 않기'를 누르는 것만으로 비밀번호가 새는 게 아니다. 그 설정 파일을 커밋하고 저장소를 공개했을 때 샌다"고 썼다. 아피로의 본문도 같은 조건을 적고 있다. 저장소가 비공개라면 공개 노출은 아니다.

클로드 코드 팀의 보리스 체르니도 댓글을 남겼다. 설정 파일은 원래 로컬에 두는 것이고, 클로드가 파일을 만들 때는 자동으로 gitignore 에 넣는다는 설명이다. 이번 사례는 손으로 만들어 커밋한 파일이라는 것이다. 권한 규칙 대신 자동 모드를 쓰는 쪽이 안전하다는 입장도 함께 밝혔다.

반대편 의견도 있다. 자격 증명을 1Password 에 두고 클로드가 보지 못하게 하며, 필요할 때 op CLI 를 불러 지문으로 승인한다는 이용자도 있었다. 원문 설정 파일을 커밋할 일이 있으면 암호화 저장소를 쓰라는 조언도 붙었다. "git add . 는 유해하다"는 한 줄짜리 반응이 가장 많은 공감을 받았다.

지금 확인할 것 — rotate 먼저, 정리 나중

아피로가 제시한 순서는 네 단계다. ① 조직의 GitHub에서 .claude/settings.local.json 과 settings.json 을 검색한다. ② 지금 없어도 git 기록에 있었는지 확인한다. 기록에 있으면 포크와 복제본에도 있다. ③ 내 기기의 사본에서 허용 목록을 읽고 비밀이 들어간 규칙을 찾는다. ④ 비밀을 찾았으면 지우기 전에 먼저 교체(rotate) 한다. 지우는 것으로는 기록·포크·복제본이 정리되지 않는다.

재발을 막는 방법은 두 가지다. 비밀을 명령에 직접 쓰지 않고 $DB_URL 같은 변수로 넘기면 규칙에는 변수 이름만 남는다. 명령 전체가 아니라 Bash(npm run:*) 처럼 패턴으로 승인한다.

보안팀이 볼 곳은 .env 만이 아니다. .claude/·.cursor/·.gemini/·.specstory/ 폴더와 에이전트 메모리 파일을 비밀 취급 대상에 넣고, 커밋 전 검사와 CI 검사에 히스토리까지 포함해야 한다. 쓰는 스캐너가 PGPASSWORD=·sshpass·bearer 헤더처럼 명령줄 안의 비밀번호를 잡는지도 확인해야 한다.

설정 파일 하나가 회사 데이터베이스를 여는 열쇠가 될 수 있다. 오늘 할 일은 검색이 아니라 교체다.

원문: Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub (Apiiro Research, 2026년 11월 5일)

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.