클로드 코드 유출 물량은 curl이 절반, 살아 있는 자격은 DB와 SSH에 몰렸다

Google 검색에서
선호 출처로 추가

선호 출처로 추가하면 Google 주요 뉴스에 위키트리 기사가 더 자주 표시됩니다.

깃가디언, 클로드 코드 설정 파일 속 비밀 3만 1,088개 발견…5,343개는 유효
도커 허브 이미지에도 613개 유입, 앤트로픽은 비밀 스캔 등 대책 검토

검은 화면의 노트북과 열쇠·케이블이 놓인 나무 책상 풍경 — 내용 이해를 돕는 AI 이미지
검은 화면의 노트북과 열쇠·케이블이 놓인 나무 책상 풍경 — 내용 이해를 돕는 AI 이미지

앤트로픽(Anthropic)의 코딩 도구 클로드 코드에서 “Yes, and don't ask again”(예, 다시 묻지 않기)을 누르면 명령어에 든 비밀번호와 API 키가 설정 파일에 그대로 저장된다. 이 파일이 공개 깃허브에 올라간 사례를 보안 업체 깃가디언(GitGuardian)이 집계했다. .claude/settings.local.json 안에서 찾은 서로 다른 비밀 정보는 3만 1,088개, 저장소는 2만 3,276곳이다. 이 중 5,343개는 탐지 당시 실제로 작동하는 자격 증명이었다.

앞서 보안 업체 아피이로(Apiiro)가 같은 파일을 분석해 문제를 알렸다. 깃가디언은 푸시되는 모든 공개 커밋을 실시간으로 스캔한 결과라며 2025년 1월부터 2026년 11월 7일까지 데이터를 내놨다. 지금 노출된 양이 아니라 한 번이라도 올라갔던 양을 센 수치다.

승인 한 번이 ‘명령어 통째 허용 규칙’으로 저장된다

구조는 단순하다. 개발자가 클로드 코드에 n8n 서버의 워크플로 목록을 불러오라고 시킨다고 하자. 클로드 코드는 API 키가 담긴 curl 명령을 제안하고 실행 전에 허락을 구한다. 개발자가 오후 내내 이 API를 쓸 생각에 “Yes, and don't ask again”을 고르면, 그 명령어 문자열 전체가 허용 규칙으로 프로젝트 폴더의 settings.local.json에 기록된다. API 키도 함께 들어간다.

클로드 코드는 이 파일이 깃에 올라가지 않도록 막는 장치를 두고 있다. 사이버시큐리티뉴스(Cybersecurity News)에 따르면 파일을 처음 쓸 때 개발자의 전역 깃 무시 파일에 제외 항목을 추가한다. 그러나 이 설정은 프로젝트와 함께 이동하지 않는다. 다른 컴퓨터나 오래된 클론에서 작업하거나 이미 깃이 추적 중인 파일이면 다른 파일과 함께 커밋된다.

아피이로는 11월 5일(현지시각) 발표한 조사에서 공개 깃허브의 파일 사본 10만 4,185개를 확인했다. 실제 비밀이 든 파일은 1,122개, 서로 다른 비밀은 1,379개였다. 데이터 수집은 11월 1~3일에 이뤄졌다. 과거 버전과 팀 공유 설정 파일, 저장된 에이전트 대화 기록까지 더하면 1,994개 저장소에서 2,539개로 늘어난다. 영향받은 조직은 63곳이다. 이 중에는 의료 기록 앱 클라우드 데이터베이스의 소유자 비밀번호와 결제 서비스 운영 환경 인증 정보가 있었다.

노트북 자판을 두드리며 화면 앞에서 작업하는 모습 — AI로 생성한 자료 이미지
노트북 자판을 두드리며 화면 앞에서 작업하는 모습 — AI로 생성한 자료 이미지

깃가디언 검사 결과 유효 비밀 최소 5,343개 확인

깃가디언 집계로 settings.local.json에서는 7만 1,525건의 노출이 확인됐다. 고유 비밀은 3만 1,088개, 저장소 2만 3,276곳, 푸시한 개발자는 1만 1,336명이다. 팀이 공유용으로 커밋하는 settings.json에서도 고유 비밀 8,271개와 저장소 6,839곳이 나왔다. 이 파일의 5,343개는 전체의 17%다. settings.json에서는 1,283개가 유효했다.

깃가디언의 유효성 검사는 공개 탐지마다 자동으로 도는 읽기 전용 확인이다. 검사 결과가 나온 건만 따지면 settings.local.json 노출의 67%, settings.json 노출의 57%가 유효했다. 검사기가 없는 탐지기는 유효로 세지 않는다. 깃가디언은 5,343개를 최소치로 본다.

아피이로의 1,379개와 깃가디언의 3만 1,088개는 서로 다른 질문에 답한다. 깃가디언은 아피이로가 현재 사본에는 보수적 필터를 적용했고 유효성 검사는 하지 않았다고 설명했다. 아피이로는 현재 사본에서 1,379개, 이력에서 734개를 집계했다. 깃가디언은 한 번이라도 푸시된 모든 비밀을 셌다. 후자가 교체해야 할 자격 증명의 규모라는 것이 깃가디언의 설명이다.

물량은 curl, 실제로 작동하는 건 데이터베이스와 SSH

깃가디언은 약 3,000건을 표본으로 비밀이 어떤 허용 규칙에 들어 있는지 분류했다. 위치를 확인한 비밀은 모두 허용 규칙이나 환경 변수 블록에 있었고 거부 규칙에 든 것은 없었다. 규칙의 절반(50%)은 curl 명령이었고 베어러 토큰, JWT, 헤더 속 API 키 등이 담겼다. 다만 이쪽은 유효 비율이 낮았다.

살아 있는 자격 증명은 다른 곳에 몰렸다. PGPASSWORD= 같은 변수 접두 명령이 15%였고 확인 가능한 것의 29%가 유효했다. psql, mysql, mongosh, redis-cli 등 DB 접속 명령은 4%인데 유효 비율이 50% 이상이었다. sshpass 계열은 1%지만 54%가 유효했고 일부는 루트 비밀번호였다. 깃가디언은 물량은 curl이고 유효한 자격 증명은 데이터베이스와 SSH라고 요약했다.

settings.local.json에만 유효한 포스트그레스(Postgres) 접속 문자열이 고유 1,955개(유효 노출 5,076건) 들어 있었다. SSH 비밀번호 292개, 몽고DB 주소 116개, 구글 API 키 941개, 텔레그램 봇 토큰 355개, 리센드 키 142개, 딥시크 키 186개도 유효했다. 계열별로는 데이터베이스 식별 정보가 2,280개로 가장 많고 클라우드 토큰 971개, AI 토큰 583개가 뒤를 이었다.

도커 허브로 번진 유출과 스캐너의 사각지대

유출은 깃허브에서 끝나지 않았다. 도커 파일의 COPY . . 명령은 깃 인덱스가 아니라 작업 디렉터리를 통째로 복사한다. 그래서 공개 도커 허브 이미지에도 비밀 613개가 실렸고 99개가 유효했다. 유효한 클라우드플레어 API 토큰 하나는 이미지 태그 559개에서 반복 발견됐다.

기존 스캐너도 이 유출을 충분히 잡지 못했다. 아이티뉴스에 따르면 비밀이 든 1,122개 파일 중 gitleaks는 564개, TruffleHog는 643개를 잡았고 215개는 둘 다 놓쳤다. 사이버시큐리티뉴스는 PGPASSWORD=, sshpass -p, 요청 헤더 뒤에 붙은 비밀번호가 제공업체 발급 키 같은 뚜렷한 형식이 없어서라고 전했다. 파일은 개발자 PC에도 평문 JSON으로 남는다. 아이티뉴스는 2025년 9월 슈라이훌루드 npm 웜이 피해자 파일에 TruffleHog를 돌렸던 사례를 들었다.

4월 정점 뒤 92% 줄었지만 원인은 불명

깃가디언 집계에서 월별 노출은 2026년 4월 1만 2,535건으로 정점을 찍었다. 10월에는 959건으로 92% 줄었다. 깃가디언은 무엇이 달라졌는지 아직 모른다고 밝혔다. 아이티뉴스에 따르면 평문 자격 증명 저장 문제는 2025년 8월부터 깃허브 이슈로 보고돼 왔다. 체크포인트 소유의 라케라는 4월 npm 패키지 30개에서 이런 파일 33개를 찾았다.

앤트로픽의 클로드 코드 총괄 Boris Cherny는 11월 7일 해커뉴스 토론에서 문제를 인정했다. 그는 “지금까지 클로드 코드는 비밀 정보 제거를 하지 않았지만(이를 위한 좋은 도구가 많다), 막기 위해 할 수 있는 일을 살펴보고 있다”고 말했다. 아이티뉴스에 따르면 자동 모드가 이런 명령을 걸러내게 하거나 기본적인 비밀 스캔을 넣는 방안을 시제품으로 만들 계획이지만 완전한 해법이 못 될 수 있다고 했다. 자동 모드에서도 같은 노출이 가능하다는 독자 지적에는 “좋은 지적”이라고 답했다. 그는 클로드 코드가 파일 생성 때 깃 무시 처리를 하므로 노출된 사본은 수동으로 만들어 체크인된 것이라고도 주장했다.

대응 순서는 두 업체가 비슷하다. 아피이로는 파일을 지우기 전에 파일에 담겼던 모든 자격 증명부터 교체하라고 권고했다. 삭제해도 깃 이력과 포크, 클론에 남기 때문이다. 이어 git rm --cached로 추적을 해제하고 .gitignore에 경로를 추가하라고 했다. 명령에 비밀번호를 직접 쓰지 말고 환경 변수나 비밀 관리자를 참조하게 하고, 명령어 전체가 아니라 패턴 단위로 승인하라는 권고도 있다.