GitGuardianが最近行った分析では、開発者エンドポイントのサンプルから平均150件の秘密情報が検出されました。そのうちプライベートキーが固有シークレットの38%を占め、クラウド、IDプロバイダー、シークレット管理ツール（AWS IAM、HashiCorp Vault）の認証情報がさらに22%を占めています。
これらの数値は、すべての開発者マシンに普遍的に当てはまる推定値として捉えるべきではありませんが、方向性としては重要な意味を持ちます。セキュリティチームが通常ソフトウェアサプライチェーンと定義する範囲の外側で、どれほど多くの認証情報が蓄積されうるかを示しているからです。
さらに驚くべき発見は、一部の秘密情報が現れた場所です。コーディングエージェントのヒストリーファイルから多数の秘密情報が見つかったのです。これはセキュリティチームが真っ先に調査する場所ではありません。プロンプト、ツール呼び出し、デバッグ出力、生成されたコードスニペット、アシスタントのコンテキスト、そしてローカルツールが残したその他の痕跡——つまり、現代の開発作業が生み出す「操作上の残滓」にほかなりません。
開発者マシンに秘密情報が存在することは、誰もが知っています。しかし現代の開発ツールが秘密情報を残している場所を、AppSecチームはほとんど把握できていないため、問題の規模はおそらく過小評価されています。
問題はコードが本番環境に到達する前から始まっている
ソフトウェアサプライチェーンセキュリティは、コードベースに何が入り込むかという問いとして語られることが多いです。どのパッケージがビルドに取り込まれ、どの依存関係に脆弱性があり、どのワークフローが本番認証情報に触れられるか——そうした観点からの議論が中心です。
それらの問いは重要ですが、より単純な事実を覆い隠してしまう可能性があります。攻撃者は、悪意あるコードを本番環境に届けなくても目的を達成できるということです。開発者ワークステーションが一台でも侵害されれば、次の攻撃の足がかりとなるだけのローカルアクセスを露出させてしまいます。
業界はこれまで何年もかけて、ソースコードに秘密情報を書かないことを開発者に教えてきました。その教訓は今も重要ですが、コーディングエージェント、ローカルCLI、IDEプラグイン、MCP設定、AI支援ツールといった現代の開発手法——これらが静かにセンシティブなコンテキストを保持しうることには対応できていません。
Shai-Hulud、Megalodon、Miasmaといったパッケージ・拡張機能・CIパイプラインを標的とした最近のサプライチェーン攻撃の波は、孤立したパッケージ整合性の失敗としてではなく、認証情報を収集するキャンペーンとして捉えるべきです。悪意あるコンポーネントは多くの場合、配送手段に過ぎません。開発者マシンは本番環境よりも認証情報に近い位置にあるため、ROIの高い標的となっているのです。
最近の攻撃波に見られる共通パターン
ごく最近、Trivy、Checkmarx AST、GitHub、LiteLLM、Telnyx、RedHat、Axiosが次々と侵害されるか、連鎖的なサプライチェーンインシデントに巻き込まれました。
攻撃の経路はパッケージを介するものもあれば、開発ツールやCIワークフローを介するものもありましたが、共通する特徴は「認証情報に手が届く場所で、信頼されたコードが実行された」という点です。そうなれば、脆弱なコードが一行もコミット・レビュー・デプロイされる前に攻撃は成功してしまいます。開発者ワークステーションやCIランナー上で実行されるということは、その環境の信頼を引き継ぐことを意味するからです。
Nx Consoleはその典型例でした。人気のVS Code拡張機能の悪意あるバージョンが、SSHキー、.envファイル、クラウド認証情報、パッケージトークン、Vaultトークン、1Password CLIのアクティブなセッション情報など、開発者のローカル秘密情報を収集しようとしたのです。GitHubのようなセキュリティ成熟度の高い企業でさえ、被害を免れることはできませんでした。
初期実行から重要なアクセス権限までの距離を一気に縮められることから、開発者の認証情報はサプライチェーン攻撃者にとって自然な標的となっています。ワークフロー一つが侵害されれば、リポジトリへのアクセス権、パッケージの公開権限、クラウドアクセス、あるいは別のダウンストリーム侵害へとつながっていきます。
盲点は開発者が実際に作業する場所にある
ほとんどのAppSecプログラムは、開発者のラップトップよりもリポジトリとCIの方を明確に把握しています。ソフトウェアサプライチェーンをソース・ビルド・アーティファクト・デプロイメントとしてモデル化していた頃はそれで通用しましたが、現代の開発はその境界を曖昧にしています。
開発者のワークステーションは単なるエンドポイントではありません。ソース管理、パッケージのインストール、クラウドアクセス、AIツール、そしてローカルテストが一か所に集まる場所です。また、それらのツールが残すローカルな痕跡も蓄積されます。
防御側にとって、これらのファイルは見えにくいものです。コードレビュー、リポジトリスキャン、CIポリシーといった通常の経路の外側に存在し、所有権が曖昧になる交差点にあるためです。AppSec、エンドポイントセキュリティ、ID管理、サプライチェーンリスクのいずれもが開発者マシンに関与していますが、開発者がインストールするもの、ローカルで実行されるツール、それらのツールがアクセスできる秘密情報について、全体像を常に把握しているチームは存在しません。
そのためAppSecチームにとって、もはやスレッドモデルの外に置いておけない問いがあります。悪意あるコードが開発者の作業環境で実行された場合、何にアクセスできてしまうのか——という問いです。
開発者エンドポイントも秘密情報セキュリティの対象
以上のことは、リポジトリスキャン、依存関係レビュー、CI強化、プッシュ保護の重要性を損なうものではありません。これらの対策は引き続きセキュリティの基盤をなします。
ただし、攻撃者が信頼された開発ツールを認証情報収集の経路として利用しているのであれば、AppSecはリポジトリとCIでメンタルモデルを止めるわけにはいきません。開発者エンドポイントは秘密情報セキュリティの一部です。ソフトウェア開発と認証情報の露出が実際に交わる場所だからです。
開発者のラップトップは、ITが管理する単なるエンドポイントではなく、特権を持つソフトウェアサプライチェーンのノードです。そこに秘密情報が蓄積されれば、AppSecが削減すべき攻撃対象領域の一部となります。
サプライチェーン攻撃者はすでにその調整を済ませています。AppSecプログラムも同じ調整を行う必要があります。
翻訳元: https://www.helpnetsecurity.com/2026/06/04/attackers-secrets-developers-machines/
