Dek: 「Yes, and don't ask again」を押すと、通したコマンドがそのままプロジェクトの設定ファイルに残る。APIキーを含んだまま、公開リポジトリに上がっていた。
Claude Code secrets leakの起点は許可ボタン
Ars Technicaが11月9日に報じ、Cybernewsも同じ日に扱った。公開GitHubのリポジトリに、Claude Codeの設定ファイル経由で認証情報が数千件あふれている、という内容だ。
原因は攻撃ではない。開発者が「Yes, and don't ask again」を押すと、Claude Codeはそのコマンド文字列を許可ルールとして、プロジェクト内の.claude/settings.local.jsonへ書き込む。APIキー付きのcurlを通せば、キーごと残る。
Claude Code settings.local.jsonが追跡される理由
Claude Codeは、このファイルを自分で作ったときに手元のgit除外リストへ入れる。リポジトリ側には何も入らない。古いclone、fork、すでに追跡されていたファイルでは、そのままコミットされる。
GitGuardianの集計では、公開GitHub上のsettings.local.jsonから3万1,088件の認証情報が見つかり、2万3,276のリポジトリにまたがっていた。検出した時点で実際に使えたものは5,343件にのぼる。設定ファイルがノートPCの外へ出るだけで、鍵は生きている。
AI agent secret leakはDockerイメージにも乗る
GitHubの外にも出口がある。COPY . . でリポジトリを丸ごとイメージへ入れると、gitが無視しているファイルも一緒に入る。.dockerignoreに.claude/を書いていなければ、イメージは鍵を抱えたまま公開される。
GitGuardianは公開Docker Hubで613件の認証情報を数え、99件が有効だったと報告している。あるクラウドのAPIトークンは、1つのイメージの559タグに現れた。リポジトリからファイルを消しても、押し出したイメージは残る。
Claude Code GitHub securityの検査が拾えない形
既存のスキャナは鍵の形を覚えている。PGPASSWORD= や sshpass -p の後ろに直書きされたパスワードは、その形を持たない。Apiiroの測定では、gitleaksとTruffleHogが漏えいファイルの5つに1つを取りこぼした。
GitGuardianのデータでも、検出の63%は汎用パターンだ。プロバイダー形式の鍵だけを見ていると、この問題の大半は見えない。
削除より先に失効させる
では、どこから手を付けるか？ 順番を間違えると、消したつもりで終わる。最初にやるのは、そのファイルが持っていた可能性のある鍵を全部失効させることだ。履歴、fork、Dockerイメージにはコピーが残る。履歴を書き換えても届かない。
場所 | 見るもの |
|---|---|
.claude/settings.local.json | 許可ルールの中のAPIキー、パスワード、接続文字列 |
.claude/settings.json | envブロックに置かれたトークン |
CLAUDE.md | 手順書に貼られた接続文字列 |
Dockerイメージ | 上のファイルがCOPYで入っていないか |
次に、リポジトリの.gitignoreと.dockerignoreへ追加する。ファイルか/permissionsを開いて、秘密を含むルールを消す。以後は$API_KEYのように変数で書き、ルールには名前だけを残す。Bash(curl:*)のような広い許可より、URLまで指定した狭い許可のほうが安全だ。
日本のチームが今週やること
日本の受託開発では、客先のリポジトリをcloneし、検証用にforkする流れが普通にある。そのたびに設定ファイルが運ばれる。社内配布用のDockerイメージにも同じ経路がある。
AnthropicのClaude Code責任者Boris ChernyはHacker Newsで、問題を調査中で、これまで秘密の除去はしてこなかったと認めている。自動モードと秘密スキャンの試作も進むが、解決しきるとは言っていない。
Claude Codeが破られたわけではない。設定ファイルを人が共有した結果だ。心当たりのあるリポジトリを一つ開いて、settings.local.jsonを検索するところから始めればいい。
