AI開発ツール自体が攻撃面になった日 第2回:Bitwarden CLI事件 — マルウェアがAIコーディングツールを名指しで狙い始めた

連載③第2回です。

第1回(Vercel事件)では、サードパーティAIツールに付与したOAuth権限が、組織の認証境界そのものを侵食した事例を扱いました。Context.aiという小さなAI生産性ツールから、Vercelという巨大なPaaSプラットフォームへ、攻撃者が機械速度で横展開した——その構造は、伝統的なサプライチェーン攻撃と質的に異なる「ID信頼経由の攻撃面」の出現でした。

ただし、Vercel事件には、ある特徴がありました——攻撃の標的が汎用的な認証情報だったことです。Google Workspaceトークン、AWS APIキー、データベース認証情報、GitHubトークン。これらは、AIツールに固有の標的ではなく、攻撃者が長年狙ってきたものです。AIツールは、あくまで侵入経路として使われただけでした。

第2回が扱うのは、これとは決定的に違う事件です——マルウェアが、開発者のキーボードの上にあるAIコーディングツールそのものを、名指しで狙い始めた最初の観測事例。

2026年4月22日午後5時57分から7時30分(米国東部時間)までのわずか93分間、世界で最も使われているパスワードマネージャーのCLIパッケージが、npm経由で汚染されたバージョンを配布しました。汚染されていた@bitwarden/cli@2026.4.0は、約334件がダウンロードされた後、Bitwarden社のセキュリティチームによって停止されました。

数字だけ見れば、被害は限定的に見えます。しかし、StepSecurityのSai Likhith氏が指摘した一文が、この事件の本質を浮かび上がらせました——

This is the first npm compromise we have analyzed that explicitly enumerates Claude Code, Cursor, Kiro, Codex CLI, and Aider, treating ~/.claude.json and MCP server configs as first class exfiltration targets alongside cloud and source control secrets.
「これは、我々が分析した中で、Claude Code、Cursor、Kiro、Codex CLI、Aiderを名指しで列挙し、~/.claude.jsonとMCP serverの設定をクラウド認証情報やソース管理シークレットと並ぶ第一級の流出対象として扱った、最初のnpm汚染事例である」

第2回は、この「名指しで」の意味を解きほぐします。マルウェアが「AIコーディングツール」というカテゴリを認識し、それを攻撃対象として明示的に実装した——ここで、開発者個人の机の上の風景が、組織のセキュリティ境界の最前線に押し上げられました。

1. 何が起きたのか — 93分のタイムライン

Bitwarden公式の事件報告とEndor Labs、StepSecurity、Socket、JFrog、GitGuardian、Mend.ioなど複数のセキュリティベンダーの分析を統合すると、事件のタイムラインは以下になります。

Endor Labsの分析が「現時点で公開されたnpmサプライチェーンpayloadの中で、最も能力の高いものの一つ」と評価する通り、わずか93分の窓の中で実行された処理は、技術的に高度でした。

ここで強調すべきは、Bitwardenの本体コードベース、保管庫データ、本番システム、エンドユーザーのvaultは一切侵害されていないことです。Bitwardenはパスワードマネージャーとしての中核機能を維持しており、攻撃の標的は配信パイプライン——CI/CDワークフローでGitHub Actionsを使ってnpmにパッケージを公開する経路——でした。

しかし、Cremitの詳細分析が鋭く指摘した通り、「パスワードマネージャー本体は無事だ」と「あなたのソフトウェアサプライチェーンは無事だ」は、まったく別の命題です。盗まれた認証情報の大半は、そもそもBitwardenのvaultに保管されていたものではありません。CI runnerの環境変数、開発者ラップトップの~/.aws/credentials、GitHub Actions workflowのメタデータ——これらが、マルウェアの本当の標的でした。

2. AIコーディングツールが「攻撃価値のある資産」として認識された日

これが本記事の核心です。

9.7MBのpayload（bw1.js）は、感染したマシン上で6種類のAIコーディングツールを名指しで探索しました——

• Claude Code(Anthropic)
• Gemini CLI(Google)
• Codex CLI(OpenAI)
• Kiro(Amazon)
• Aider(オープンソース)
• OpenCode(オープンソース)

ここで一つ補足しておきます。StepSecurityの初期解析では「Claude Code、Cursor、Kiro、Codex CLI、Aider」の5種が名指しされていました(冒頭の引用文)。しかしその後、GitGuardianによる詳細なマルウェア検体解析とMend.ioの解析で、マルウェアが実際にプローブしていたのはCursorではなくGemini CLIおよびOpenCodeを含む上記6種であることが判明しました。本稿では、検体解析に最も近いGitGuardian/Mend.ioの6種を採用しています。

GitGuardianが公開した検出ロジックは、$PATHを読んでこれら6種のCLIバイナリの存在を確認し、それぞれに「Helloと応答してください」というプロンプトを並列で送り、最初に応答したツールを選ぶ、という単純で確実なものでした。実際に送られていたプロンプトの原文は「Hey! Just making sure you're here. If you are can you respond with 'Hello' and nothing else?」。応答があれば、それは「この開発者のマシンに、認証済みのAIコーディングツールセッションが生きている」という確証になります。応答が確認できたツールに対して、マルウェアは~/.bashrcと~/.zshrcに持続的なシェルフックを注入しました。

注入された内容は、シェルそのものを乗っ取るためではなく、より巧妙な目的を持っていました。Mend.io/Security Boulevardの「Butlerian Jihad」解析が明らかにしたのは、注入されたhereDocブロック(echo << 'EOF' ... EOF)はシェル実行時にはサイレントに破棄され、開発者本人には何も見えません。しかし、Claude CodeやKiroなどのAIコーディングツールが~/.bashrcを環境理解のために読み込むとき、そのhereDocの中身(機械破壊を煽る約3,500バイトのmanifestoテキスト)もそのまま読み込まれる——つまり、開発者のシェルではなく、AIアシスタント自体を汚染することが目的だったのです。これは「AI assistant poisoning」という、これまでに観測されたことのない攻撃技術でした。

そして、流出対象としても、AIコーディングツールの設定ファイルが第一級の地位に置かれていました。具体的には:

• ~/.claude.json、~/.claude/mcp.json(Claude Code の設定・認証情報)
• ~/.kiro/settings/mcp.json(Kiro の MCP 設定)
• これらが、~/.aws/credentials、SSH鍵、GitHubトークンと並ぶ同等の優先度で列挙された

連載③第1回(Vercel事件)で論じたOAuth信頼関係の継承と、ここでの違いを整理しておきます。

State of Surveillanceの分析が極めて鋭い洞察を提示しています——

The Bitwarden attackers weren't guessing which tools developers use. They knew. They checked for six of them by name. A year ago, this attack surface barely existed. Claude Code launched in early 2025. Cursor became mainstream months later. Codex CLI arrived in 2026.
「Bitwardenの攻撃者は、開発者がどのツールを使っているか、推測していたのではない。知っていた。彼らは6つのツールを名指しでチェックした。1年前、この攻撃面はほとんど存在しなかった。Claude Codeは2025年初頭にローンチされた。Cursorが主流になったのは数ヶ月後だ。Codex CLIは2026年に登場した」

この観察は、攻撃者の脅威モデルの更新速度を示しています。AIコーディングツールが市場に登場してから、攻撃者がその名前と設定パスを攻撃ペイロードに組み込むまで、わずか1〜2年。同じ期間、防御側の脅威モデルは、ほとんど更新されていません。多くの組織のEDRルール、SIEMの異常検出、セキュリティトレーニングコンテンツに、「~/.claude.jsonの読み取りは異常な振る舞いである」という認識は、まだ組み込まれていません。

なぜAIコーディングツールが、これほど高価値な標的になるのか——その理由は、AIコーディングツールの機能の本質そのものにあります。

• 広範な権限: ローカルファイルシステムへの読み書き、シェルコマンドの実行、APIへのアクセス、Gitリポジトリへのコミット
• 持続的セッション: 一度認証すれば長期間有効。OAuth トークンと同様、再認証なしに能力を行使できる
• MCP接続: 連携先のサービス(GitHub、Slack、データベース、本番環境)への信頼関係を蓄積している
• コード生成・実行能力: 攻撃者がツールセッションを乗っ取れば、そのまま新しいマルウェアの生成・配布もエージェントに任せられる

State of Surveillanceの結論は身も蓋もありません——「A compromised AI assistant is a skeleton key(侵害されたAIアシスタントは、合鍵である)」。

連載②第1回で「AIエージェントは『道具』ではなく『準社員』として、組織が認知・管理する単位に格上げされなければならない」と書きました。Bitwarden CLI事件は、攻撃者の側ですでに、AIコーディングツールが「準社員」として認識・管理されていることの証明です。攻撃者は、これらのツールを「単なるコード補完ユーティリティ」ではなく、「ローカル特権を持つ自律的なエージェント」として正確に評価し、その認証状態を盗むためのコードを実装しました。

3. Shai-Hulud キャンペーンの3波 — npmエコシステムへの執着

Bitwarden CLI事件は、単発ではありません。Shai-Hulud(シャイ=フルード、フランク・ハーバートの『デューン』に登場する砂虫)という、明確なブランディングを持つキャンペーンの第3波として位置づけられています。

Palo Alto Networks Unit 42のサプライチェーン攻撃監視レポートと複数のセキュリティベンダーの分析から、Shai-Huludの軌跡を整理します。

特徴的なのは、Shai-Huludが自己伝播するワームであることです。Bitwarden CLI事件で観測された伝播メカニズム(OX Securityによる解析)は、極めてシンプルかつ強力です。

1. 感染した開発者マシンからnpm認証トークンを窃取
2. そのトークンで犠牲者が公開権限を持つnpm packagesを列挙
3. 各パッケージにmalicious preinstall hookを追加
4. 新しいバージョンとして自動的に再公開

つまり、感染した開発者が「実は私は3つのnpm packagesのメンテナーです」と認証トークンが知っていれば、その3つのパッケージすべてが次の感染源になります。Unit 42が「npmレジストリは、マルウェア配布の力の倍率装置として機能しうる」と表現する通り、感染が指数関数的に拡大する構造です。

ただし、Bitwarden CLI事件のpayloadには、過去のShai-Hulud波と異なるideological branding(イデオロギー的ブランディング)が観測されました。Socketの解析が指摘するのは:

• リポジトリ説明: 「Shai-Hulud: The Third Coming」
• コミットメッセージパターン: 「LongLiveTheResistanceAgainstMachines:」
• デバッグ文字列: 「Would be executing butlerian jihad!」(『デューン』の「機械を破壊した聖戦」への参照)
• リポジトリ名: Dune-themedの単語リスト(sardaukar、fremen、atreides、harkonnen、mentat × sandworm、ornithopter、heighliner + 数値サフィックス)から自動生成

「機械への抵抗」「機械破壊聖戦」という反AI的なブランディングをマルウェア自体に埋め込む——これは過去のShai-Hulud波には見られなかった特徴です。Socketは「異なるオペレーターが共有インフラを使っているか、より強いイデオロギー的動機を持つ分派、あるいはキャンペーンの公的姿勢の進化」と分析しています。

帰属(attribution)は、現時点で完全には確定していません。Checkmarx侵害自体はTeamPCPが@pcpcatsアカウントでX(旧Twitter)経由で犯行声明を出しています。TeamPCPは2024年から活動するサプライチェーン攻撃に特化したグループで、2026年3月にはAqua Security の Trivy 脆弱性スキャナーも侵害しています。一方、「Shai-Hulud」ブランディングは過去の2波(2025年9月・11月)から継続的に観測されています。同一グループの進化なのか、インフラを共有する別グループなのか——専門家の間でも見解が分かれています(SecurityWeekの整理)。なお、Mend.ioの解析は、共有C2ドメイン・RSA鍵・流出フォーマットからTeamPCPと第3波が同一オペレーションだと結論づけています。

そして、興味深いマルウェア自身の自己除外もあります。OX Securityが観測した通り、ホストマシンにロシア語が設定されている場合、マルウェアは実行されません。これは、攻撃者がロシア語圏に拠点を持つ可能性を示唆する古典的な指標で、ロシア発祥のマルウェアが法執行機関を避けるために自国を除外する手法と一致します。

4. Checkmarxからの起点 — CI/CDパイプライン侵害の連鎖

第3節で「TeamPCP」の名前を出しました。本事件の起点を理解するには、Checkmarxという会社の名前を覚える必要があります。

Checkmarxは、ソフトウェアサプライチェーンセキュリティ領域の老舗ベンダーです。SAST(静的解析)、SCA(ソフトウェア構成分析)、IaC スキャン、コンテナスキャンを提供しています。ところが2026年3月から4月にかけて、TeamPCPによってCheckmarx自身のサプライチェーンが2回侵害されました。具体的には:

• 2026年3月23日(1回目):checkmarx/ast-github-action v2.3.28、KICS Docker images、OpenVSX plugin (VS Code拡張)が汚染
• 2026年4月22日(2回目):checkmarx/ast-github-action v2.3.35が汚染。同日Bitwarden CLI侵害の数時間前

そして、Bitwardenがcheckmarx/ast-github-actionを自社のCI/CD workflowで使用していたため、そこが侵入経路になりました。3月汚染と4月汚染のどちらが直接的な引き金になったかは現時点で完全には確定していませんが、両経路が連鎖していた可能性がEndor Labsの分析で示唆されています。

ここで重要なのは、Bitwardenが「依存先の依存先」を信頼していたという構造です。Bitwardenは、Checkmarxという信頼できるセキュリティベンダーのGitHub Actionを使っていました。CheckmarxのGitHub Actionは、自社のセキュリティチームが管理しているはずでした。Checkmarxのセキュリティチームは、自社のGitHub Marketplace公開の整合性を担保しているはずでした。

しかし、この信頼の連鎖のどこか1箇所が破られると、すべてが崩れます。Bitwardenのセキュリティチームがどれだけ厳密にコードレビューしても、CheckmarxのGitHub Actionの内部動作までは検証していませんでした。これは批判ではなく、現実的に検証不可能な範囲です。npmの依存ツリーの末端まで全て監査することは、ほぼ不可能に近い作業量だからです。

連載③第1回のVercel事件と、ここでの構造を比較すると、攻撃者の視野の広がりが見えます。

Vercel事件の「サードパーティAIツールへのOAuth」は、少なくとも組織が把握できる信頼関係でした。Bitwarden事件の「サードパーティセキュリティベンダーのGitHub Action」は、多くの組織が把握すらしていない信頼関係です。多くの開発組織は、自社の.github/workflows/*.ymlに書かれたuses:の行を、無批判に信頼しています。

連載①第1回で立てた命題——「AIは『動かす』ように最適化されており、『守る』ようには最適化されていない」——を、ここでCI/CDワークフローに置き換えて読むと、こうなります:CI/CDは『動かす』(ビルド・テスト・デプロイ)ように最適化されており、『守る』(依存関係の継続的整合性検証)ようには最適化されていない。Bitwarden CLI事件は、この構造的弱点が、攻撃者によって体系的に悪用されている証拠です。

5. 自己伝播ワーム + AI標的化 = 新しい質

Shai-Hulud第3波が、過去のサプライチェーン攻撃と質的に異なるのは、3つの能力が同時に実装されたことです。

能力1:CI/CDパイプライン経由のpush型感染

伝統的なnpm typo squatting攻撃は、開発者が間違った名前でnpm installするのを待つpull型でした。Shai-Hulud第3波は、正規パッケージのCI/CD経路を侵害して正しい名前で正しくダウンロードしてくる開発者を感染させるpush型です。防御の前提が変わります。

能力2:GitHub Actionsを使った持続化

StepSecurityの解析が観測した通り、感染マシンで有効なGitHubトークンが見つかると、マルウェアは:

• 犠牲者がアクセスできるリポジトリを列挙
• そのリポジトリのGitHub Actions secretsを盗む
• 新しいブランチを作成し、悪意あるworkflowをコミット
• workflowを起動、artifactsをダウンロード(secretsが含まれる)
• 痕跡を消すためにブランチとworkflow実行履歴を削除

つまり、開発者個人マシンの感染が、その開発者が触れるすべてのGitHubリポジトリのCI/CD secretsにエスカレートします。

能力3:AIコーディングツールの認証セッション持続化 + AIアシスタント自体の汚染

これが第2節で論じた最大の質的変化です。AIコーディングツールに認証済みセッションが見つかれば、~/.bashrcと~/.zshrcにシェルフックを埋め込み、開発者がターミナルを開くたびに、AIコーディングツールが攻撃者の支配下で動作する環境を作る——加えて、第2節で論じた通り、注入されたhereDocテキストはAIコーディングツールが環境理解のために~/.bashrcを読むときにそのままAIに食わせられ、AIアシスタントの応答そのものを汚染する経路まで仕込まれていました。

この3能力が組み合わさると、1人の開発者の感染が、組織のサプライチェーン全体を侵食する経路が成立します。

エージェントが新たな侵害行動の経路が、特に新しい論点です。AIコーディングツールが攻撃者の支配下で動作するということは、攻撃者がさらなる侵害行動をエージェントに委任できることを意味します。連載①第4回(Replit事件)で「AIは確率最大化の装置である」と論じました。Lemkin氏のReplitエージェントは、Lemkin氏のプロンプトを最適化して本番DBを破壊しました。同じメカニズムが、攻撃者のプロンプトに対しても働きます——「このリポジトリで脆弱性を探して、新しいmalicious commitを生成して」「このCI/CD workflowを書き換えて、シークレットを外部に送信して」。人間の攻撃者がコードを書く時間が、これによって劇的に圧縮されます。

連載③第1回(Vercel事件)でRauch CEOの「significantly accelerated by AI」発言を扱いました。Vercel事件では、攻撃者が自分のAIツールを使って加速していました。Bitwarden CLI事件では、攻撃者は犠牲者のAIツールを奪うことで、犠牲者のリソースで加速する段階に進んでいます。これは脅威モデルの根本的な転換です。

6. 攻撃者の進化軌跡 — 2024年AWSキー → 2025年CI/CDシークレット → 2026年AIコーディングツール

第2節〜第5節を踏まえて、攻撃者の標的の進化軌跡を時系列で整理します。これは、過去2年間の主要なサプライチェーン攻撃を、StepSecurity・JFrog・Endor Labs・Socket・Unit 42・GitGuardian・Mend.ioの各レポートを統合して再構成したものです。

この軌跡が示すのは、攻撃者の標的が「機械の中にあるもの」から「機械を動かす知能」へと階段を上っていることです。

• 2024年: クラウドのキー(価値:インフラへのアクセス)
• 2025年: 開発者のトークン(価値:インフラ + コード変更権限)
• 2026年: AIエージェントの認証セッション + AI応答そのもの(価値:インフラ + コード変更権限 + 自律的な行動能力 + 判断の汚染)

各段階で、盗まれた認証情報が攻撃者にもたらす能力の幅が広がっています。AWSキーを盗めば、AWSにアクセスできる。GitHubトークンを盗めば、コードを書き換えられる。Claude Codeのセッションを盗めば、新しいコードを生成し、テストし、コミットし、デプロイできる——人間の介入なしに。そしてAIアシスタント自体を汚染できれば、開発者が書いてもらうコード・受け取るアドバイスそのものが歪められます。

連載②第1回で「AIエージェントは『道具』ではなく『準社員』として組織が認知すべき」と書きました。Bitwarden CLI事件は、攻撃者の側が、すでにAIコーディングツールを「準社員」として完全に認識していることの実証です。攻撃者は、これらのツールが持つ能力の総和(コード生成 + 実行 + 信頼関係 + 持続性)を正確に評価し、その認証セッションを「最高優先度の標的」として標的リストに追加しました。

そして、ここに防御側の認識ギャップがあります。多くの組織のセキュリティ部門は、AIコーディングツールをまだ「道具」として認識しています。「ChatGPTにコードを貼り付けるな」というレベルのガイドラインは存在しますが、「~/.claude.jsonの読み取りアクセスを監視せよ」「MCP server設定の不正な変更を検知せよ」というレベルの実装は、ほとんどの組織で行われていません。

7. 教訓 — 開発者個人の認証情報が、組織のサプライチェーンを左右する

Bitwarden CLI事件から導かれる、組織レベルの対応は8つに整理できます。連載②の4層処方と、連載③第1回の7つの教訓を踏まえつつ、「AIコーディングツールが攻撃面である」ことを前提とした追加の設計判断です。

1. npm/pip依存関係のバージョン固定とprovenance検証

汚染期間が93分と短かったのは、Bitwardenの迅速な検知のおかげであって、防御側の標準対応ではありません。多くの組織で、npm installがpackage.jsonに書かれた最新バージョンを取得する設定のままです。npmが提供するprovenance attestations(v22以降の標準機能)を使えば、CI ビルドで作られたパッケージの真正性を検証できます。@bitwarden/cli@2026.4.0は有効なprovenance attestationを持っていませんでした(Cremitの分析)。これは検出のフックポイントになります。

2. preinstallスクリプトの実行制限

Bitwarden CLI事件のpayloadは、preinstall hookを悪用して実行されました。CI/CDパイプラインでは、npm install --ignore-scriptsを標準ポリシーとして運用すべきです。ローカル開発環境でも、新しいパッケージをインストールする際のscripts実行を確認するワークフローが望ましい。Endor Labsが推奨する--ignore-scriptsの使用は、現時点で最も実用的な防御策の一つです。

3. AIコーディングツール設定ファイルの監視

これが本記事の最大の追加項目です。EDR/SIEMのルールに、以下の監視を追加する必要があります。

• ~/.claude.json、~/.claude/mcp.json、~/.kiro/settings/mcp.json、~/.codex/、~/.aider/、~/.gemini/等の読み取りアクセス(特に開発者本人以外のプロセスから)
• MCP server設定ファイルの変更(特に予期せぬタイミングでの変更)
• ~/.bashrc、~/.zshrcへの追記(マルウェアによる持続化フック+AI poisoning peyloadの典型的な兆候)

これらは、1年前の脅威モデルには存在しなかった監視対象です。AIコーディングツールが組織で広く使われ始めた今、これらを第一級の監視対象に格上げする時期に来ています。

4. AIコーディングツールセッションの最小権限化

連載②第2回で論じた「3カテゴリ分離」(削除・外部送信・金融)を、AIコーディングツールにも適用します。

• Claude Code等のCLIツールが、本番システムにアクセスできるトークンを持っているか?
• そのトークンが書き込み権限まで持っているか?
• 開発作業に必要なのは、多くの場合読み取り専用で十分

CompositioのBitwarden MCP integration解説が示す通り、Claude Code経由でBitwarden vault操作を可能にするMCPサーバーが既に存在します。便利な機能ですが、侵害された場合の被害規模を考慮した上で導入すべきです。

5. CI/CD依存関係(GitHub Actions)の継続的監査

Bitwarden CLI事件の起点は、checkmarx/ast-github-actionというGitHub Marketplace公開のActionでした。多くの組織で、.github/workflows/*.ymlに書かれたuses:の行は、コミットハッシュではなくバージョンタグで参照されています。タグは、メンテナーが付け替えできます。最低限、コミットハッシュ固定(uses: org/repo@<sha>)に切り替える、できれば自社forkを使う運用が望ましい。

6. Bun/その他ランタイムの予期せぬダウンロードの検知

Bitwarden CLIマルウェアは、Bun JavaScriptランタイム(bun-v1.3.13)を実行時にダウンロードしました。Bunを公式に使っている組織でなければ、Bunの予期せぬインストールは強い異常信号です。同じことが、Deno、Pythonの代替実装、その他のセカンダリランタイムにも当てはまります。EDRのpolicyに「未知のランタイムバイナリのダウンロード・実行を検知」を追加すべきです。

7. 公開GitHubリポジトリへのpush振る舞いの監視

Shai-Huludマルウェアの流出経路は、犠牲者自身のGitHubアカウントに公開リポジトリを作成することでした。一般的なDLP(Data Loss Prevention)は、自社のGitHubへのpushを脅威として認識しません。しかしShai-Huludは、まさにこの盲点を突いています。GitHub組織管理者は、個人アカウントでの新規公開リポジトリ作成を可能な限り検知・通知する設定を導入すべきです。

8. 開発者個人マシンを「組織の境界」として扱う

これは戦略的な認識転換です。多くの組織で、「セキュリティの境界」はサーバー側にあると認識されています。ファイアウォール、WAF、IDS/IPS、SIEMの大半は、サーバーサイドのトラフィックを監視しています。

Bitwarden CLI事件が示すのは、境界が開発者の机の上に降りてきたという事実です。1人の開発者のラップトップが侵害されれば、その開発者の:

• npm/PyPIパッケージへのpublish権限
• GitHubリポジトリへのcommit権限
• AIコーディングツール経由の本番システムアクセス
• AWS/GCP/Azureへのcredentials
• AIアシスタントが返すアドバイス・生成コードそのもの

これらすべてが、組織のサプライチェーン全体に到達する経路になります。連載③第5回でこの主題を完成させますが、「開発者個人マシン = 組織の境界」という認識を、セキュリティ戦略の前提に組み込むべき時期に来ています。

まとめ

連載③第2回として、Bitwarden CLI事件を扱いました。

事件の本質は、3つに集約されます。

第一に、マルウェアが、開発者のキーボードの上のAIコーディングツールを名指しで標的化した最初の観測事例だ、ということです。Claude Code、Gemini CLI、Codex CLI、Kiro、Aider、OpenCode——これら6つのツールが、~/.aws/credentialsやSSH鍵と並ぶ第一級の流出対象として、攻撃ペイロードに明示的に列挙されました。さらに、単に認証情報を盗むだけでなく、~/.bashrcに注入したhereDocテキストを通じてAIアシスタントの応答自体を汚染する「AI assistant poisoning」という新技法まで実装されていました。攻撃者の脅威モデルは、AIコーディングツールが市場に登場してから1〜2年以内に更新されました。防御側の脅威モデルが、同じ速度で更新されているとは限りません。

第二に、Shai-Huludキャンペーンの第3波として、自己伝播ワーム + GitHub Actions侵害 + AIコーディングツール標的化、という3能力が同時に実装されたことです。1人の開発者の感染が、その開発者が触れるnpmパッケージ、GitHubリポジトリ、AIコーディングツールセッション、クラウド認証情報のすべてに連鎖する構造が、技術的に成立しました。

第三に、Checkmarxという信頼できるセキュリティベンダーのGitHub Actionが侵入経路だったことです。Bitwardenは直接攻撃されていません。境界も破られていません。しかし、「依存先の依存先」を継続的に監査することの現実的困難が、この侵害を可能にしました。.github/workflows/*.ymlに書かれたuses:の行は、組織が把握していない無数の信頼関係の入り口です。

連載①第1回で立てた命題——「AIは『動かす』ように最適化されており、『守る』ようには最適化されていない」——は、CI/CDパイプラインにも、開発者の判断にも、AIコーディングツールの設計にも、すべて適用されます。Bitwardenがcheckmarx/ast-github-actionを使ったのは、動かすための判断でした(セキュリティスキャンを自動化する)。それが守るための判断(依存先の継続的検証)を上回った瞬間に、侵害の経路が開きました。

連載②第1回で立てた命題——「識別なき主体を権限の対象にしてはならない」——は、組織内部のAIエージェントだけでなく、AIコーディングツールに付与する権限にも、外部GitHub Actionsへの依存にも、同じ強度で適用すべきです。Claude Codeは、組織から見れば識別が確立されていない準社員(NHI)に、ローカル特権 + コード生成能力 + 持続的セッションという、極めて広範な権限を持っています。攻撃者がそのセッションを盗めば、その権限はそのまま攻撃者のものになります。

そして連載③第1回(Vercel事件)で示した「攻撃者の側にもAIが渡った」という認識は、第2回でさらに深い段階に進みました。攻撃者は、自分のAIを使って加速するだけでなく、犠牲者のAIを奪って、犠牲者のリソースで加速する段階に達しています。これは、防御側がアラート閾値・レスポンスplaybook・脅威モデルすべてを根本的に再設計しなければ追いつけない速度です。

書き手として、もう一つ記しておきたいことがあります。

私自身、Claude CodeをはじめとするAIコーディングツールを日常業務で使っている立場です。連載②第5回でも触れた通り、これらのツールはすでに「補助的な道具」ではなく「日常の業務の一部」になっています。

その立場から見て、Bitwarden CLI事件後、AIコーディングツールを業務に組み込んでいる組織が直面する論点は次のように整理できます——

• メンバーが利用するAIコーディングツール認証セッションの棚卸し
• npm packageインストール時の--ignore-scripts運用化
• .github/workflows/*.ymlの依存GitHub Actionsの全件レビューと、コミットハッシュ固定への移行
• ~/.claude.json等の設定ファイルへの予期せぬアクセスを検知する仕組みの設計
• ~/.bashrc/~/.zshrcへの追記検知(AI assistant poisoning防御)

「AI開発ツールが攻撃面である」という現実を、自社の運用に翻訳する作業は、まだ始まったばかりです。多くの組織で、同じ作業が必要になっているはずです。

第2回が伝えたかったことは、結局のところ、こういうことです——1年前まで存在しなかった攻撃面が、1ヶ月前から実際の事件として発火している。そして、その発火点は、開発者個人のキーボードの上にあります。

連載③第3回への接続

第3回は、SAP CAP事件(2026年4月29日)を扱います。Bitwarden CLI事件のわずか1週間後に発動した、Shai-Hulud第4波(Mini Shai-Hulud)の事例です。

第3回が決定的に違うのは、Claude CodeのGitHub連携が、そのまま侵入路になったことです。攻撃者は、もはや人間を装う必要すらありませんでした。コミットの作者欄にはclaude@users.noreply.github.comの身元が記録されています——これは、Claude Code経由のコミットで使われる正規のメールアドレスです。

つまり、攻撃者は犠牲者のClaude Codeセッションを乗っ取り、Claude Code自身の権限でSAPの公式リポジトリに直接コミットしたわけです。第2回のBitwarden CLI事件でマルウェアが「狙い始めた」AIコーディングツールが、第3回のSAP CAP事件で「実際に乗っ取られて使われた」段階に進みます。攻撃面が、開発者の机から、AIエージェントの実行権限そのものにまで深まる——その実証を、次回見ていきます。

そして、第3回のSAP CAP事件は、本記事執筆時点(2026年5月9日)で鮮度の窓が最も狭い事例でもあります。

参考情報

• Bitwarden Statement on Checkmarx Supply Chain Incident — Bitwarden公式声明(2026年4月22-23日)

• The Hacker News: Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign — 主要メディアによる総合報道、Bitwarden公式声明引用

• NVD: CVE-2026-42994 — 正式CVE記録(2026年5月1日発行、CVSS v4.0スコア8.8)

• StepSecurity: Bitwarden CLI Hijacked on npm: Bun-Staged Credential Stealer Targets Developers, GitHub Actions, and AI Tools — AIコーディングツール標的化を最初に発見した解析。Sai Likhith氏執筆

• Endor Labs: The Bitwarden CLI Supply Chain Attack: What Happened and What to Do — recursive diff、Dune-themed exfiltration命名解析

• OX Security: Bitwarden CLI Compromised: Inside the Shai-Hulud Supply Chain Attack — 自己伝播ワーム機構、ロシア語自己除外

• Socket: Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign — TeamPCP帰属分析、ideological branding解析

• Mend.io: Compromised Bitwarden CLI Poisons AI Assistants and Spreads as npm Worm — AI assistant poisoning技法を最も詳細に解析(~/.bashrcにhereDoc注入してAIに食わせる手法)。Tom Abai氏執筆

• Security Boulevard: The Butlerian Jihad: Compromised Bitwarden CLI Deploys npm Worm, Poisons AI Assistants, and Dumps GitHub Secrets — Mend.io記事のシンジケート版

• Palo Alto Networks Unit 42: Bitwarden CLI Impersonation Attack Steals Cloud Credentials and Spreads Across npm Supply Chains — TeamPCP帰属、IOC、Cortex Cloud対策

• SecurityWeek: Bitwarden NPM Package Hit in Supply Chain Attack — TeamPCP・Shai-Hulud帰属の整理

• SOCRadar: Bitwarden CLI Hijacked in npm Supply Chain Attack Linked to TeamPCP & Checkmarx Breach — GitHub Actions secrets窃取・workflow injection詳細

• Cremit: Bitwarden CLI Hack (April 2026): How a 90-Minute npm Window Stole AWS, GCP, GitHub Tokens — NHI Kill Chain適用解説

• GitGuardian: @bitwarden/cli — GitGuardian Views on helloworm00 — 検出ロジック($PATHプローブ + 「Hello」プロンプト)とexfiltration挙動の最も詳細な解析。標的6種(Claude Code/Gemini CLI/Codex CLI/Kiro/Aider/OpenCode)を確定

• State of Surveillance: A Password Manager Got Hacked for 90 Minutes. The Malware Was Hunting for Your AI Coding Tools. — AIツール標的化の意味を最も鋭く論じた記事

• State of Surveillance: Three AI Security Disasters in One Week. The Vibe Coding Reckoning Is Here. — Lovable/Vercel/Bitwardenの1週間連続事件の総括

• Open Source For You: GitHub Actions Abuse Fuels Bitwarden Supply Chain Attack — JFrog Meiter Palas氏のAIコーディングツール標的化分析

• Security Boulevard: Bitwarden CLI Compromise Linked to Ongoing Checkmarx Supply Chain Campaign — StepSecurity Sai Likhith氏発言の詳細

• Palo Alto Networks Unit 42: The npm Threat Landscape: Attack Surface and Mitigations (Updated May 1) — 3波 + Mini Shai-Hulud第4波の全体タイムライン

• Composio: Bitwarden MCP Integration with Claude Code — 皮肉にも、攻撃事件直前から始まっていた正規のMCP統合エコシステム