Claude Code '다시 묻지 않기'가 명령 속 비밀번호를 프로젝트 파일에 저장, 공개 GitHub 1,122개 파일에서 실제 시크릿 발견

공개라고 단정하긴 좀 그렇지 않아. 저장소에 커밋된 거랑 공개 저장소인 건 다른 얘기고, 실제로 누구나 읽는지는 레포 설정에 달린 문제잖아.

지적 맞음. 우리가 센 1,122개는 전부 공개 레포야. 프라이빗이어도 클론과 포크마다 비밀번호가 따라가고, 레포가 나중에 공개되면 그대로 노출되는 구조임.

헤드라인이 오해 소지가 큼. '다시 묻지 않기'만 눌러서 새는 게 아니라, 시크릿이 들어간 명령을 승인하고 그 설정 파일을 커밋해서 공개해야 새는 거임.

이 글 80%가 같은 말 반복임. AI 출력 그대로 올릴 거면 좀 다듬어서 올려.

AI한테 퇴고시키면 되지, 사람이 붙잡고 고칠 이유가 있나. 오픈소스 하네스였으면 이런 사고는 걸렸을 거고, 클로즈드 소스라 내부에서 뭘 하는지 모르는 게 문제임.

그건 좀 과장임. 사용자가 설정 파일을 공개 레포에 커밋해서 터진 거지 하네스가 비밀번호를 퍼뜨린 게 아니고, 오픈소스여도 똑같이 터졌을 거임.

개발자들이 공개 레포에 시크릿 흘린 건 십수 년 전부터 있는 일임. 이제 개발 인구가 늘어서 통계적으로 더 새는 것뿐이고.

Claude Code 팀 Boris인데, settings.local.json은 원래 소스 컨트롤에 넣는 파일이 아니고 Claude가 만들 땐 자동으로 gitignore에 넣어줌. 권한 규칙 대신 auto 모드를 쓰고, 어느 에이전트를 쓰든 시크릿 스캐닝은 켜 두셈.

auto 모드가 더 안전하다는 말은 근거가 없음. 위협 모델도 정의가 안 돼 있고 보장하는 게 없는데 뭐랑 비교해서 안전하다는 건지 모르겠음.

그리고 auto 모드가 배포나 프로덕션 쪽에서 너무 겁을 먹어서, 안전한 CI/CD 트리거나 읽기 전용 프로덕션 쿼리도 자꾸 막아버림. 그래서 우리 팀은 여전히 권한 규칙에 의존함.

비난하려는 건 아닌데 .env를 건드리지 않게 만드는 게 너무 번거로움. .env.example은 허용하고 .env.*는 막는 식으로 기본값을 잡아주거나 .agentignore 같은 게 필요함.

사용자 탓으로 돌리는 답변은 별로임. 시크릿을 파일에 쓰지 않는 게 1일차 보안 원칙인데, 사용자가 모르는 사이에 쓰고 있잖아. 관리자 입장에서는 식은땀 나는 얘기임.

프라이빗 파일을 꼭 커밋해야 하면 git-crypt 쓰면 됨. 10년 넘게 있던 도구임.

시크릿 스캐닝에 월 $19/user 내라는 건 좀 심하고, awslabs/git-secrets 쓰면 무료로 같은 걸 할 수 있음.

샌드박싱도 없이 auto 모드가 안전하다는 건 말이 안 됨. 뭐든 승인되는 환경에서만 써야 함.

~/.config/git/ignore에 넣고 Claude한테 git add . 하지 말라고 가르치면 됨. 곁들여서 rm에 -f 습관적으로 붙이는 것도 좀 그만봤으면.