승인 창의 버튼 하나가 명령 원문을 파일에 적어 넣었다. 그 파일이 저장소를 따라 공개됐다.
Apiiro Claude Code 조사가 시작된 지점
편의 기능이 출발점이었다. 문제는 Claude Code 승인 창의 ‘예, 그리고 다시 묻지 않기’(don't ask again) 버튼이다. 보안 업체 Apiiro는 11월 5일 공개한 분석에서 이 버튼이 승인한 명령을 자격 증명까지 포함해 그대로 저장한다고 밝혔다.
저장 위치는 프로젝트 폴더의 .claude/settings.local.json이다. 같은 명령을 다시 묻지 않도록 허용 규칙을 적는 파일이고, 규칙 옆에 명령 원문이 따라붙는다. 접속 명령을 한 번 허용하면 비밀번호까지 그 줄에 남는다.
settings.local.json이 공개 저장소로 간 경로
파일 형식은 문제가 아니다. Claude Code는 저장소 안에서 이 파일을 만들 때 개발자의 전역 gitignore 목록에 자동으로 추가하지만, 그 보호는 프로젝트를 복제하거나 다른 저장소에 올리는 순간 사라지고 파일만 남는다.
Apiiro는 공개 사본 104,185개를 103,617개 저장소에서 확인했다. 그중 1,122개 파일에 1,379개의 서로 다른 비밀이 들어 있었다.
Claude Code secrets leak, 무엇이 새졌나
무엇이 새는지 보면 범위가 잡힌다. 해당 파일에는 공급자 형식을 갖춘 키 636개와, 공개 호스트에 묶인 비밀번호·토큰 743개가 함께 들어 있었다. 데이터베이스 비밀번호 379개와 Supabase 서비스 역할 키 122개도 같은 묶음이다.
Supabase 계정 토큰 103개와 SSH 자격 증명 43개도 목록에 있다. SSH 항목 중에는 sshpass 명령 안에 루트 로그인을 적은 사례가 있었고, AWS 키 23개와 개인 키 6개도 함께 나왔다.
Claude Code credentials, 2,539개의 비밀
범위를 넓히면 숫자가 커진다. 공유 설정 파일과 대화 기록, git 이력을 합치면 1,994개 공개 저장소에서 2,539개의 비밀이 확인됐다. 조직 63곳이 영향을 받았고, 이 값은 파일 수가 아니라 서로 다른 비밀의 개수다.
과거 버전에는 현재 사본에 없는 비밀 734개가 남아 있었고, 포크는 74개 저장소의 자격 증명을 211개 사본으로 옮겼다.
Claude Code 스캐너가 놓친 줄
탐지 도구도 전부 잡지는 못했다. Gitleaks는 비밀이 든 파일 564개를, TruffleHog는 643개를 표시했다.
탐지되지 않은 215개가 문제다.
왜 두 도구 모두 이 줄을 놓쳤을까? PGPASSWORD=나 sshpass -p, mysql -p 뒤에 붙는 비밀번호는 공급자 접두사가 없어 정규식이 알아보지 못한다. 사람 눈에는 접속 정보로 보인다.
Claude Code credentials 회전 순서
Apiiro가 권하는 순서는 삭제가 아니라 회전이고, 노출된 자격 증명을 먼저 바꾸고 파일을 추적에서 제거한 뒤 저장소 단위 ignore 규칙을 넣고 과거 커밋과 공유 설정, 대화 기록까지 확인한 다음 리터럴 값을 비밀 관리자 참조로 바꾸는 것이다.
노출된 키가 살아 있었다고 확인한 조직은 한 곳이고, Apiiro는 자격 증명을 시험하지 않았다. 여기서 말하는 비밀은 로그인이 검증된 값이 아니라 신뢰할 만한 자료다.
국내 팀도 같다. GitHub 조직 저장소에 .claude 폴더를 올리고 키를 명령줄에 넣는 방식은 국경과 상관이 없다. Anthropic은 이번 보고서에 입장을 내지 않았고, 이 패턴이 다른 도구에 얼마나 퍼졌는지도 공개된 자료가 없다.
‘영구 허용’은 화면 설정이 아니라 자격 증명을 어디에 저장할지 정하는 결정이다.
