기준: 보안 회사 Apiiro 블로그 글(2026년 11월 5일 공개, 11월 8일 원문 확인). 조사 기간 2026년 11월 1~3일, 공개 깃허브 읽기 전용 검색. 숫자는 모두 Apiiro가 밝힌 것이며, 조사팀은 찾은 키를 직접 써 보지 않았습니다.
AI 코딩 도구로 바이브코딩을 하다 보면 "이 명령 실행해도 될까요?"라는 확인 창을 하루에도 몇 번씩 봅니다. 귀찮아서 'Yes, and don't ask again(다시 묻지 않기)'를 누르는 순간, 그 명령에 들어 있던 비밀번호가 프로젝트 폴더의 설정 파일에 그대로 적힐 수 있습니다. 이 파일이 저장소에 같이 커밋되면 깃허브에 공개됩니다.
비밀번호는 어떻게 설정 파일에 들어가나요?
허락한 명령이 '문자열 그대로' 허락 규칙으로 저장되기 때문입니다. Apiiro 설명에 따르면 클로드 코드에 "스테이징 서버 로그인이 왜 실패하는지 봐 줘"처럼 데이터베이스나 API를 다루는 일을 맡기면, 도구가 제안하는 명령에는 설정 파일에서 가져온 비밀번호가 들어갑니다. 명령이 돌아가려면 비밀번호가 필요하기 때문입니다.
이때 'Yes, and don't ask again'을 고르면 다시 묻지 않도록 프로젝트 폴더의 .claude/settings.local.json 허락 목록(permissions.allow)에 규칙이 하나 더해지는데, 그 규칙이 명령 문자열 그 자체입니다. 아래 그림은 가짜 값으로 다시 그린 예시입니다. PGPASSWORD= 뒤의 비밀번호까지 그대로 남습니다.
이 파일은 원래 올라가지 않는 파일 아닌가요?
원래는 내 PC에만 남도록 만든 파일이지만, 막아 주는 장치가 내 PC에만 있습니다. Apiiro에 따르면 클로드 코드는 git 저장소 안에서 이 파일을 만들 때 개발자 PC의 '전역' git 제외 목록에 파일을 추가합니다. 흔한 경우는 이것으로 막힙니다.
하지만 저장소의 .gitignore에는 들어가지 않습니다. 그래서 아래 경우에는 그대로 커밋될 수 있습니다.
- 처음엔 그냥 폴더였다가 나중에 git 저장소가 된 경우
- 다른 PC에서 저장소를 새로 복제해 작업한 경우
- 누군가 이미 한 번 커밋해 둔 경우
파일만 지우면 끝일까요?
아닙니다. 파일을 지워도 git 커밋 이력과 포크 · 복제본에는 그대로 남습니다. 아래는 가짜 값으로 만든 예시 저장소에서 실제로 실행한 결과입니다. 파일을 지우는 커밋(d67aa1d)을 만든 뒤에도, 그 전 커밋(06e47eb)을 git show로 열면 비밀번호가 든 규칙이 그대로 보입니다.
Apiiro도 같은 점을 강조합니다. 이력에 남아 있으면 그 저장소를 포크하거나 복제한 모든 곳에도 남아 있으니, 지우기보다 비밀번호를 바꾸는 것이 먼저라고 권고합니다.
실제로 얼마나 올라가 있었나요?
Apiiro는 공개 깃허브에서 .claude/settings.local.json 104,185개를 찾았고, 그중 1,122개(1.1%)에 비밀정보가 들어 있었다고 밝혔습니다. 서로 다른 비밀정보는 1,379개였고, 그중 데이터베이스 비밀번호가 379개, Supabase service-role 키가 122개였습니다.
영향을 받은 조직은 63곳이고, Apiiro는 11월 2~3일 각 조직에 알렸다고 합니다. 그중 한 곳은 키가 실제로 쓸 수 있는 상태였다고 확인했습니다. 다만 Apiiro가 말하는 '진짜 비밀정보'는 알려진 키 형식이거나 공개 서버 주소와 함께 적힌 비밀번호라는 뜻이고, 조사팀은 키를 써 보지 않았습니다. 1,379개가 모두 지금 쓸 수 있는 키라는 뜻은 아닙니다.
비밀정보 검사 도구로 잡을 수 있지 않나요?
상당수는 못 잡습니다. Apiiro가 비밀정보가 든 파일 1,122개를 검사 도구 두 개로 돌려 보니 gitleaks는 564개, TruffleHog는 643개 파일을 잡았고, 215개 파일은 둘 다 놓쳤습니다.
| 검사 도구 | 잡은 파일(1,122개 중) |
|---|---|
| TruffleHog | 643개 |
| gitleaks | 564개 |
| 둘 다 놓침 | 215개 |
놓친 이유는 비밀번호가 '키 모양'이 아니어서입니다. 검사 도구는 서비스별 접두어나 긴 무작위 문자열 같은 키 형식을 찾는데, PGPASSWORD= · sshpass -p · mysql -p 뒤에 사람이 적은 비밀번호는 평범한 명령의 평범한 단어처럼 보입니다.
지금 내 저장소에서는 무엇을 하면 되나요?
순서가 중요합니다. Apiiro 권고를 따라 아래 순서로 하면 됩니다. 2번 명령은 가짜 값 예시 저장소에서 실제로 실행해 본 결과를 영상에 담았습니다.
- 비밀번호 · 키부터 바꾸기. 파일에 한 번이라도 들어간 비밀번호와 키는 모두 새로 발급합니다. 파일을 지워도 이력 · 포크 · 복제본에는 남기 때문입니다.
- 추적 끊고 .gitignore에 넣기.
git rm --cached .claude/settings.local.json으로 저장소 추적만 끊고(내 PC의 파일은 남음), 저장소의.gitignore에.claude/settings.local.json줄을 더합니다. - 명령에는 환경 변수 쓰기. 비밀번호를 명령에 직접 적지 말고
$DB_URL같은 환경 변수로 부르게 하면, 허락 규칙에도 비밀번호 대신$DB_URL만 남습니다.
파일을 커밋한 적이 없더라도 한 번 열어 보세요. Apiiro는 허락 목록을 열어 비밀번호 · 토큰 · 키 · 접속 주소가 든 규칙을 모두 지우라고 권합니다. 앞으로는 명령 하나하나를 허락하기보다 Bash(npm run:*)처럼 패턴으로 허락하는 편이 안전합니다.
다른 AI 코딩 도구는 괜찮은가요?
같은 습관이면 같은 위험이 생깁니다. Apiiro는 .claude/뿐 아니라 .cursor/ · .gemini/ · .specstory/ 같은 AI 도구 폴더와 에이전트 메모리 파일도 .env처럼 비밀이 든 파일로 다루라고 권합니다. 명령 속에 비밀번호를 적으면, 도구가 실행 기록 · 대화 기록 · 인수인계 메모 어디에 적든 똑같이 남기 때문입니다.
한 번에 정리
- '다시 묻지 않기'는 명령을 통째로
.claude/settings.local.json에 저장한다. 명령 속 비밀번호도 함께. - Apiiro 조사: 공개 파일 104,185개 중 1,122개에서 비밀정보 1,379개, 215개 파일은 검사 도구 두 개가 모두 놓침(11월 5일 발표).
- 지우기만으로는 부족하다. 커밋 이력 · 포크에 남는다.
- 할 일 순서: 비밀번호 바꾸기 →
git rm --cached+ 저장소.gitignore→ 명령에는 환경 변수, 허락은 패턴으로. .cursor·.gemini같은 다른 AI 도구 폴더도 같은 기준으로 점검한다.
출처
- Apiiro, "Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub"(2026.11.5) — https://apiiro.com/blog/coding-agents-leaking-secrets-github-dont-ask-again
- GeekNews 소개 글 — https://news.hada.io/topic?id=36784
- 글 속 허락 창 그림은 설명을 위해 다시 그린 예시이고, 설정 파일 · git 화면은 가짜 값으로 만든 예시 저장소에서 실제로 실행한 결과입니다.