持ち去られるものが何も無いべきだ

昨日、改ざんされた Bitwarden の CLI が、334 台の開発者マシンから SSH 鍵、AWS 資格情報、npm トークン、環境変数、シェル履歴、Git の秘密情報を収集しました。

本日は Bitwarden でした。先月は Axios。その前は Checkmarx。明日は VS Code 拡張機能かもしれません。Acrobat かもしれません。Homebrew の formula かもしれません。Docker イメージかもしれません。攻撃経路は毎週変わります。結果は常に同じです。

マルウェアが侵入します。~/.ssh/ を読みます。~/.aws/credentials を読みます。~/.npmrc を読みます。~/.git-credentials を読みます。シェル履歴、環境変数、ブラウザのパスワードストアを読みます。すべてをまとめて、C2 サーバーへ送信します。

そして、成功します。毎回成功します。

収集されたもの

Bitwarden のペイロード —— bw1.js という 10 MB の難読化されたファイル —— は、暗号の解読を試みませんでした。その必要がなかったからです。Socket と Aikido の記録によれば、収集したのは次のとおりです。

• SSH 鍵とホストのフィンガープリント
• AWS、GCP、Azure のクラウド資格情報
• npm 認証トークン
• Git 資格情報とリモート URL
• 環境変数
• シェル履歴
• Claude Code の認証情報と MCP 設定

続いて、盗んだ npm トークンを使って被害者が管理していた他のパッケージを再公開し、さらに拡散しました。被害者が攻撃経路になりました。

これらはいずれも、暗号を破ることを必要としませんでした。これらの秘密はすべて、ファイルシステム上のファイルであり、ユーザーとして実行される任意のプロセスが読み取れる状態でした。

これは Bitwarden の話ではない

Bitwarden の保管庫の暗号は破られていません。ゼロ知識アーキテクチャは機能しました。マルウェアは保管庫に一度も触れていません。

触れる必要がなかっただけです。

保管庫は、その中身を守ります。しかし SSH 鍵は元々保管庫にはありませんでした。AWS 資格情報も保管庫にはありませんでした。npm トークン、Git 資格情報、.env ファイル内の API キー —— これらはどれもパスワード管理ツールの中には存在しません。平文のまま、すべての開発者のマシン上の dotfiles に存在しています。

攻撃者はこれを理解していました。保管庫とは、すべての引き出しが開いている家の中の、施錠された金庫です。

実際の攻撃対象領域

今すぐターミナルを開いてください。マシン上に何があるかを確認してください。

~/.ssh/id_ed25519 —— 秘密鍵。平文ファイルです。

~/.aws/credentials —— クラウドへのアクセス。平文ファイルです。

~/.npmrc —— 公開用トークン。平文ファイルです。

~/.git-credentials —— リポジトリへのアクセス。平文ファイルです。

十数個のプロジェクトディレクトリにある ~/.env —— API キー、データベースのパスワード、署名用の秘密情報。すべて平文ファイルです。

ユーザーとして実行される任意のプロセスが、これらすべてを読み取れます。権限昇格は不要です。エクスプロイトも不要です。cat だけで十分です。

これが 2026 年の開発者の標準的な構成です。パスワードは暗号化された保管庫に入れ、それ以外はすべて開けたままにしておくのです。

間違った問い

サプライチェーン攻撃が起きるたびに、業界は同じ問いを発します。マルウェアの侵入をどう防ぐか。

CI/CD のセキュリティ強化、コード署名、依存関係のスキャン、サンドボックス化されたランタイム。いずれも有効です。しかし、どれも十分ではありません。攻撃対象領域が広すぎます。経路が多すぎます —— パッケージマネージャー、ブラウザ拡張機能、IDE プラグイン、OAuth アプリケーション、改ざんされたビルドツール。すべての侵入口を塞ぐことはできません。

正しい問いはこうです。マルウェアが不可避的に開発者のマシン上で実行されたとき、そこには何があるのか。

答えが「予測可能なファイルシステム上の場所に置かれた数百の平文資格情報」であるなら、サプライチェーンの強化をどれだけ進めても意味がありません。ゴールが背後で開け放たれているフィールドで守備をしているようなものです。

持ち去られるものが何も無いべきだ

対策は、より優れたマルウェア検出ではありません。npm install のサンドボックス化でもありません。インシデント対応の高速化でもありません。

対策は、秘密がディスク上のファイルとして存在しないことです。

認証の瞬間にハードウェアから導出される SSH 鍵 —— ~/.ssh/ に保存されるのではなく。ハードウェアに紐づく ID からセッションごとに発行されるクラウド資格情報 —— ~/.aws/ に書き込まれるのではなく。スコープが限定され、短命で、ハードウェアによって保護される API トークン —— .env ファイルに置かれるのではなく。

資格情報がハードウェアセキュリティモジュールの内部と、使用中の一時的なプロセスメモリにのみ存在する場合、マルウェアが読み取れるものは何もありません。持ち出せるファイルはありません。収集できる dotfile はありません。プロセスは何も見つけずに、先へ進みます。

これは理論上の話ではありません。ハードウェアに紐づく資格情報はすでに存在します。WebAuthn PRF は、認証器への物理的なタップから暗号鍵を導出できます —— その鍵はファイルシステムに触れません。技術はすでにあります。業界がそれを標準として採用していないだけです。

いま行うべきこと

Bitwarden CLI の改ざんの影響を受けた場合は、次の対応を行ってください。

• マシン上のすべての資格情報を更新する —— SSH 鍵、クラウドトークン、npm トークン、API キー、dotfiles と環境変数にあるすべてのもの
• 自分が管理する npm パッケージが再公開されていないか確認する
• GitHub のアクティビティと CI/CD ワークフローを監査し、不正な変更がないか確認する

影響を受けていない場合も、対応は同じです。マシンを確認してください。平文の秘密を数えてください。悪意ある何かがユーザーとして実行されたとき —— もしもではなく、いつか —— 何が起きるのかを自問してください。

答えは「何も起きない」であるべきです。持ち去られるものが何も無いべきなのです。