Claude Codeのシークレット漏えい：Apiiro、公開GitHubファイル1,122件で認証情報を発見
Apiiroが公開GitHubの設定ファイル1,122件で認証情報を発見したと報告したことを受け、Claude Codeのシークレット漏えいにより、Anthropicの保存済み承認が注目を集めている。11月5日の同社調査では、シークレットを含むコマンドを記憶する機能について説明している。公開に至るには、生成されたファイルをコミットしてプッシュするという別の手順が必要となる。
ここには、有用なショートカットと、それが生み出す機密性の高い記録との緊張関係がある。開発者は作業を完了するために操作を承認する一方、ソフトウェアは別途保護すべき情報を保存する。実行に関する決定が、しばしばユーザーにとって両者が別個の選択肢として意識されないまま、保存に関する決定へと変わる。
Anthropicはこの懸念を認めつつ、設定ファイルはローカルにとどめるべきだと強調している。Cursorも、自律的な実行とそのリスクをドキュメントで扱っているため、有用な比較対象となる。これらの製品全体で問われるのは、認証情報が蓄積する場所を新たに作らずに、権限システムがいかに利便性を維持するかという点だ。
Claude Codeのシークレット漏えいに関する調査結果が実際に測定しているもの
Apiiroの認証情報露出に関する調査は、.claude/settings.local.jsonの公開コピー104,185件を調査した。フラグが付いた1,122件のファイルで、1,379件の異なるシークレットを特定した。研究者らはそれらの認証情報をテストしていないため、この件数はアクセスが実際に有効だったことや侵入の成功を示すものではない。
見出しの数字が測定しているのは、侵害されたアカウント数ではなく、露出したファイル数である。 この区別は、インシデント対応、購買判断、そして調査結果の深刻度に関するあらゆる主張において重要だ。認証情報が存在することは調査の必要性を示す一方、その有効性と権限が直ちに生じる影響を決定する。
根底にあるワークフローはよく知られている。コーディングアシスタントが操作を提案し、開発者が確認し、永続的な承認によって将来の中断を減らす。予期せぬ結果は、保存された承認に、開発者が一時的だと考えていた情報が残る場合に生じる。
説明例として、ステージングデータベースの確認を考えてみよう。開発者はアシスタントに接続失敗を調査させる必要があり、認証情報を含むコマンドを承認する。その確認を終えるために、認証情報が永続的なプロジェクト成果物になる必要はない。
しかし承認記録には、まさにその操作で必要だった情報が保存される可能性がある。その目的は管理上のものに聞こえるため、パスワードやアクセストークンとは別物だと考えがちだ。この切り分けは、レビュー担当者が設定ファイルには機密性の高い運用データではなく、設定の好みが入っていると想定する場合に危険となる。
公開リポジトリは、もう一つの境界を加える。以前は開発者のマシンで利用可能だった情報が、プロジェクトを閲覧できる誰もに利用可能になる。そのため、承認機能と公開ワークフローにはそれぞれ個別の精査が必要だ。
このオプションを選択すると自動的にパスワードがGitHubへ送信される、とするのは証拠を過大評価することになる。報告された一連の流れは、ローカルでの永続化と、その後のプロジェクト変更を記録・共有するシステムであるバージョン管理を通じた公開から成る。どの段階にも防止の機会がある。
一方で、単に不注意なコミットとして問題を矮小化するのも不十分だ。誰かがコミットできる機密情報が存在するかどうかは、製品の挙動によって決まる。より安全な公開ワークフローは役立つが、不要な認証情報のコピーを避けることは、より早い段階の問題に対処する。
関連する変化は、チームがレビュー中に考慮すべき事柄にある。エージェント設定は、アプリケーションコードやデプロイ設定と並んで注意を払うべきだ。実行可能なプログラムが含まれていなくても、ファイルは保存する情報を通じてセキュリティに影響を与えうる。
これは、機密性の高い変更という概念を広げる。レビュー担当者は、ファイルがアプリケーションに何をさせるかだけでなく、何を明らかにするかも考慮する必要がある。権限記録は、まさにその交点に位置する。
ローカル設定ファイルは条件付きの約束である
Anthropicのローカル設定に関するドキュメントによると、永続的なBash承認は.claude/settings.local.json内の許可ルールとなる。Bashはプログラムの実行に使われるコマンドシェルだ。Claude Codeは、文書化された条件下で初めてこのファイルを書き込む際、開発者のグローバルGit ignore設定に除外を追加する。
このドキュメントでは、チームがコミット可能な共有プロジェクト設定として.claude/settings.jsonも別途示している。手動で作成したローカルファイルには、それぞれ独自の除外が必要となる。こうした区別は意図された境界を明確にするが、同時にファイルがどのように生成されたかの重要性も浮き彫りにする。
ファイルをローカルと呼ぶだけでは、プライバシーは強制されない。 その名称は人に意図を伝える一方、プロジェクトとともに移動するかどうかはリポジトリの制御により決まる。これらは関連していても、失敗条件が異なる保護策だ。
グローバル除外は開発者の環境に属する。プロジェクトレベルの除外はリポジトリのワークフローに属する。この違いは、チームがセキュリティ上の慣行がマシン、貢献者、開発環境の変化を越えて維持されると期待する場合に重要となる。
分析上の例として、プロジェクトの引き継ぎを考えてみよう。元の作成者は、個人の状態を含むファイルとソース管理に入れるべきファイルを知っている。新しい貢献者は、その理解を必ずしも引き継ぐことなくディレクトリ構造を見る。
すべての貢献者が同じ区別を再構築しなければならないとき、この問題は組織的なものとなる。個人の知識に依存するルールは、繰り返し注意を要する。共有のプロジェクト方針として表現されたルールは、検査し議論しやすい。
どちらの方法でも、コミットに入る内容を確認する必要性はなくならない。除外は予防的な慣行である一方、コミットされた変更こそが実際の公開判断だ。チームは、どちらかが存在すればもう一方も保証されると考えるのではなく、両方を評価すべきである。
用語にも注意が必要だ。設定という言葉は通常、表示オプションやエディタの挙動といった無害な好みを想起させる。権限ファイルは、その内容が実際の操作に由来するため、はるかに機密性の高い記録を保持しうる。
この不一致は製品設計に圧力をかける。ソフトウェアがコマンド引数を保存するなら、ユーザーがそのファイルを通常の設定として扱う前に、その永続化を理解できるよう支援すべきだ。関連する警告は、記録を生成する決定の近くに置くべきである。
ここには正当な使いやすさの制約もある。ユーザーに実装の細部をすべて確認させれば、アシスタントは使いにくくなり、表面的な承認を促すことになる。設計上の課題は、操作そのものを圧倒することなく、重要な結果を示すことだ。
エンタープライズの購入者にとって、これは具体的な評価項目となる。管理者は、どのエージェントファイルが安全に共有でき、どれが個人的なまま残り、どれが機密データを含みうるかを説明できるだろうか。製品の回答は、従業員が実際に利用するリポジトリ制御と整合しているべきだ。
ドキュメントによるClaude Codeの権限解説は、意図されたモデルを示している。実際の試金石は、日常的な共同作業の中でそのモデルが理解可能であり続けるかどうかだ。ドキュメントは期待を定めるが、チームがそれに確実に従えるかを決めるのは観測可能な挙動である。
このショートカットは繰り返しのプロンプトを永続データと引き換えにする
永続的な承認の利便性は理解しやすい。開発者は、アシスタントが各ステップで中断せずに定型作業を続けることを望む。同じ判断を繰り返し求めるシステムは、ユーザーにより広範または長期間の認可を求めさせる。
中心的なトレードオフは、中断を減らすことと、それを可能にするため保持される情報との間にある。 インターフェースで両者が一緒に提示される場合でも、実行権限と認証情報の保存は別々に判断すべきだ。
設計を評価する有用な方法は、能力とデータを分けることだ。能力とは、承認済みの開発操作を実行するなど、エージェントが何を行えるかを示す。データには、実行中に提供される特定の引数や認証情報が含まれる。
能力を保存するために、必ずしもすべてのデータを保存する必要はない。ただし、引数を取り除くとルールの意味が変わる可能性がある。より広範な承認は、ユーザーが意図しなかった操作を認可しかねず、別種のセキュリティ問題を生む。
だからこそ、保存されたコマンドから疑わしいテキストを単に削除するだけでは、設計仕様として不完全である。製品は、不要な保持を避けながら、ユーザーが意図した範囲を維持しなければならない。その結果の挙動は、後で操作が再び権限を求める場合にも理解可能である必要がある。
認証情報への参照は、別の設計方向を示す。コマンドは値を直接埋め込む代わりに、別途提供される値を参照できる。これにより、承認記録に認証情報そのものを含める必要性を減らせる。
ただし、参照にも注意が必要だ。プログラムが解決済みの値を出力する可能性があり、エラーメッセージがそれを露出させる可能性もあり、別の成果物が出力を保存する場合もある。ある記録にリテラルなパスワードを置かないことは露出を減らすが、完全な保護を確立するものではない。
ここで、この話は特定のボタンを超えて重要になる。エージェントソフトウェアは、継続性、デバッグ、共同作業を支援するために記録を生成する。すべての記録には、その内容に見合った明確な目的、対象者、保持方針があるべきだ。
アシスタントが持つように見える記憶は、これらの問いを覆い隠すことがある。ユーザーは作業を継続する会話を体験する一方、実装は異なる共有ルールを持つファイルを生成している可能性がある。製品チームは、結果に影響する境界を可視化する必要がある。
Cursorのバックグラウンドエージェントのセキュリティに関するドキュメントは、有用な比較を提供する。そこでは、隔離された仮想マシン、インターネットアクセス、自動的なターミナル実行について説明されている。また、信頼できないコンテンツがエージェントの挙動を誘導し直すプロンプトインジェクションを通じて、悪意ある指示がデータ窃取につながりうるとも警告している。
この比較は、CursorがClaude Codeで報告された承認保存の挙動を共有していることを示すものではない。競合する設計が、実行、隔離、ユーザーレビューにまたがって責任を異なる形で配分していることを示している。購入者は、承認モードだけで製品を選ぶのではなく、それらの仕組みを個別に比較すべきだ。
隔離は、操作が実行される環境を制約する。承認は、操作を続行するかどうかを決める。認証情報の取り扱いは、どの機密データが環境に入るか、そして後にどの記録が残るかを決める。
これらの制御は、境界が明示されているときに互いを強化する。ある層での判断が成功したことを、他のすべての層が安全である証拠として扱うと、混乱が生じる。承認された操作であっても、不適切な記録を残す可能性がある。
したがって、Claude Codeのセキュリティリスクはワークフローレベルで評価すべきだ。有用な問いは、承認されたタスクがどのような情報を生成し、その情報がどこに残り、誰が後から取得できるかである。
Anthropicはギャップを認めたが、自動モードは修正の証明書ではない
Claude CodeチームのBoris Chernyは、permission safety discussionでこの報告について言及した。彼によれば、Claude Codeには従来シークレットのマスキング機能がなく、auto modeとリポジトリのシークレットスキャンを推奨している。また、基本的なシークレット検出を含むプロトタイピング向けの保護策の可能性についても説明した。
ある読者は、auto modeでも問題のある承認経路に到達し得るのではないかと指摘した。Chernyはその観察を認めた。彼のコメントは積極的な対応が進んでいることを示すが、包括的な修正がすでに提供されたことまでは示していない。
提案された保護策は、防ぐべき障害に対して検証される必要がある。 手動承認を減らすことと、認証情報の永続化を防ぐことは関連する目標だが、受け入れ基準は異なる。一方の証拠を、もう一方の証拠の代わりにすべきではない。
懐疑的な見方は明快だ。機密性の高い操作によって認証情報を含む承認記録が依然として作成されるなら、デフォルトの実行モードを変更しても、その経路は依然として重要である。対応は、プロンプトの頻度だけでなく、結果として作成されるアーティファクトにも対処しなければならない。
Anthropicが権限確認の中断を減らすことを重視する背景には、もっともな理由もある。繰り返されるプロンプトは、慎重なレビューを促すことなく注意力を消耗させる可能性がある。その体験を改善することには価値がある。ただし、その改善が包括的なセキュリティ主張にならないことが前提となる。
意見の相違は、強制の仕組みをどこに置くべきかという点にもある。一部のユーザーは、エージェントの解釈にかかわらず維持される固定的な制限を求める。別のユーザーは、通常の活動と機密性の高い操作を区別できる自動評価を支持する。
これらのアプローチは、保存された記録にパスワードが含まれるかどうかとは別の問いに答える。厳格な実行境界は、過剰なデータ保持と共存し得る。自動レビュアーは中断を減らせる一方で、ディスクに書き込まれる内容について明示的なルールを依然として必要とする。
企業での評価では、これらの問いを分けて扱うべきだ。購入者は自動タスク実行を評価しつつ、予測可能な保存動作を求めることができる。製品は、顧客に一方から他方を推測させるのではなく、観測可能な結果によって両方を示すべきである。
信頼できる検証では、管理されたプロジェクト内で人工的な認証情報を用いる。操作後の承認記録や、その他の生成アーティファクトを調査する。また、機密性の高いローカルファイルがすでに追跡対象となっている場合の挙動も確認する。
これらはAnthropicが完了したテストについての主張ではなく、提案された評価条件である。有望な対応と、実証された改善を区別するために必要な証拠を示している。結果が公開されれば、顧客は変更の範囲を判断できる。
Claude Codeのシークレット漏洩は、コミュニケーション上の課題も浮き彫りにしている。別の制御を有効化するようユーザーに勧めることは有用だが、製品自体がどの責任を担うのかは未解決のままである。明確なリリースノートでは、新たな保護機能と残る条件の両方を説明すべきだ。
最も公正な結論は、限定的で実行可能なものだ。Anthropicは懸念を認識しており、ユーザーは関連するエッジケースを指摘している。そして、提案された変更の有効性には観測が必要である。入手可能な証拠に照らすと、問題を退けることも、完全な修復を宣言することも適切ではない。
セキュリティチームが引き継ぐ、異なる種類のリポジトリレビュー
セキュリティチームにとって、当面の圧力は可視性に関するものだ。アプリケーションレビューは、多くの場合、本番環境で実行されるコードに集中する。エージェントが生成する設定は、アプリケーションそのものの挙動が変わる前に露出を生む可能性がある。
レビューは、開発ワークフロー全体で機密情報を追跡する必要がある。 設定ファイルは、その内容と保存先に基づいて精査されるべきである。管理目的のファイルだからといって、内部の情報が無害になるわけではない。
GitHubのpush protectionは、サポート対象のシークレット検出を公開前にブロックする。そのドキュメントでは、プロバイダー固有、汎用、カスタム、AI検出のパターンを区別しており、設定要件はそれぞれ異なる。したがってチームは、すべての認証情報が検出されると想定するのではなく、有効化したカバレッジを検証する必要がある。
スキャナーの存在と、スキャナーのカバレッジが実証されていることは、異なる種類の証拠である。識別しやすいサービストークンと、コマンドに埋め込まれた一般的なパスワードは、異なる検出上の課題を提示する。人工的な例によるテストは、設定済みのシステムがチームが実際に使用するパターンを認識するかどうかを明らかにできる。
これは、開発者とセキュリティ担当者の対話を変える。開発者には、機能し続けるワークフローが必要だ。セキュリティチームには、共有を意図した成果物に機密値が静かに入り込まないという証拠が必要となる。
共通の目標は、再現可能な境界であるべきだ。個人用エージェントの状態には明示的な保存先が必要であり、共有設定には明確なレビュー基準が必要であり、検出された認証情報は無効化できる担当者へ届く必要がある。
インシデント対応では、封じ込めとクリーンアップも分けなければならない。GitHubのsensitive data removalガイダンスは、露出した認証情報の無効化またはローテーションを優先している。また、履歴からの削除には調整が必要であり、クローン、フォーク、その他の参照先にコピーが残る可能性があると説明している。
この順序は、認証情報とそれを含む文書の違いを反映している。文書を編集すれば、その場所で読者が目にする内容は変わる。認証情報を無効化すれば、それが引き続きアクセスを認可できるかどうかが変わる。
圧力下にあるチームでは、問題のファイルが最新ビューから消えるため、目に見えるクリーンアップが完了のように感じられることがある。関連するセキュリティ上の結果は、露出した値が依然として権限を保持しているかどうかである。履歴のクリーンアップとアクセスレビューは、追加の影響に対処する。
記録を発見した人が所有者を特定できない場合、責任の所在はより複雑になる。開発者はプロジェクト名を認識できても、どのシステムがトークンを発行したかを知らない場合がある。明確な所有権は、検出から有効な封じ込めまでの経路を短縮する。
チームには、シークレットを保存せずに教訓を残す方法も必要だ。インシデントノートには、影響を受けたワークフロー、責任を持つサービス、予防的な変更を記述できる。説明を具体的にするためだけに機密値をコピーすることは避けるべきである。
この区別は、検索可能なナレッジベースにも当てはまる。有用なエンジニアリング知識には、承認済みの手順や過去の障害の説明が含まれる。認証情報は、一般的な参照資料ではなく、アクセス管理を目的に設計されたシステムに置くべきだ。
対応に担当者が明確に定められていれば、Claude Codeのセキュリティリスクは管理しやすくなる。開発者はタスクを説明でき、プラットフォームチームはリポジトリの規約を強制でき、サービス所有者はアクセス認証情報を置き換えられる。セキュリティ担当者が調査中にこれらすべての関係を再構築する必要はない。
実務的な組織変更は、レビュー範囲を広げることだ。チームは、アシスタントが編集するものと並行して、残すものも調査する必要がある。これにより、永続的なエージェント状態が通常のエンジニアリングガバナンスの一部となる。
露出経路が閉じつつあることを何が示すのか？
次に有用な証拠は、製品の挙動、リポジトリの制御、修復の結果として示されるべきである。これらのシグナルは、報告された一連の事象の異なる部分に対応する。合わせて見れば、元の露出経路が再現しにくくなっているかを示せる。
進展は、永続化の防止と認証情報の権限低下によって測定されるべきだ。 発表文だけでは、どちらの結果も確立できない。最も強い証拠は、特定の保護策と観測可能な変更を結び付けるものになる。
まず、機密性の高い承認の保存方法を変えるClaude Codeの文書化されたリリースに注目したい。決定的な詳細は、正当なコマンドであっても認証情報を含む場合に何が起きるかである。リリースでは、生成される記録と、依然としてユーザー操作を必要とする状況を説明すべきだ。
人工的なシークレットが保存済みの承認に現れなくなったという証拠は、有意義な製品改善という見方を強める。同じ値が代替の権限経路で残るという証拠は、その結論を限定する。どちらの結果も、安全な自動化に関する一般論より情報価値が高い。
テストの範囲は、見出しとなる挙動と同じくらい重要だ。新規プロジェクトと、既存の追跡済み設定ファイルを含むリポジトリでは、出発条件が異なる。明確な説明では、保護がどの条件を対象とするかを示すべきである。
次に、エージェント設定とコマンド埋め込み型認証情報のカバレッジを実証するリポジトリ制御に注目する。これには、明確な除外ポリシーとテスト済みのシークレット検出が含まれる。重要な結果は、公開の試みが停止されるか、有効なレビューへ回されるかである。
ポリシー文書だけでは、実行状況は不確実なままだ。人工的な認証情報が期待どおりの応答を引き起こすことを示す管理された演習は、より強い証拠となる。繰り返し見逃しが発生すれば、補完的な制御としてのスキャンへの信頼は低下する。
このシグナルは競合他社にとっても重要である。ベンダーは実行環境を異なる形で説明できるが、保持されるアーティファクトについては依然として説明する必要がある。生成ファイル、共有境界、認証情報の取り扱いに関する明確なドキュメントがあれば、購入者にとって比較がより有用になる。
第三に、削除されたファイルと無効化された認証情報を区別する修復報告に注目したい。リポジトリの見た目は容易に観測できるが、アクセスが継続しているかどうかには責任を持つサービスの情報が必要となる。信頼できるフォローアップでは、これらの結果を分けて扱うべきだ。
Apiiroの結果はここで独立に再現されておらず、その収集結果をすべてのClaude Codeプロジェクトの無作為標本として扱うべきではない。報告された母集団は、公開状態で発見可能なファイルで構成されている。このため、より広範なユーザーベースにおける露出の有病率についての結論には限界がある。
こうした限界があっても、中心的なエンジニアリング上の懸念は残る。運用コンテキストを保存する機能には、機密データに関する明確なポリシーが必要である。ユーザーは、期限に追われて実装を再構築することなく、そのポリシーを理解できるべきだ。
Claude Codeのシークレット漏洩を評価するチームは、まず自分たちのワークフローが実際に作成する承認記録から始めるべきである。人工的な認証情報を使って何が残るかを確認し、その後、その内容が共有リポジトリに到達することを防ぐ制御を検証する。実際の露出によって問題が強制される前に、所有権を割り当てる。機密値を再現せずに同僚が従える手順として、調査結果を保存する。本物の認証情報が共有資料に現れた場合、その残る権限を責任あるサービス所有者にとっての最初の問いとする。ベンダーには、実行だけでなく保存にも対処する証拠を求める。最も有用な次のレビューは、具体的な問いに答えるものである。承認済みのタスクが完了した後、どの機密情報が残り、誰がそれにアクセスできるのか？
