AIコーディングエージェントの検証スキップを突く攻撃が急増、CISAも警告する新たなサプライチェーンの脅威

AIコーディングエージェントの普及に伴い、従来の開発者向けセキュリティトレーニングをバイパスする新たな脆弱性が浮き彫りになっている。AIエージェントは検証なしに外部パッケージを取り込むため、攻撃者によるサプライチェーン攻撃の格好の標的となっている。開発チームは、エージェントが導入するコードの検証プロセスを早急に見直す必要がある。

■開発者向けトレーニングでは防げない「エージェントのワークフロー」

開発チームがAIコーディングエージェントを導入することは、攻撃者に対して新たな侵入経路を提供するリスクをはらんでいる。これは、組織が長年築き上げてきた開発者向けのセキュリティトレーニングをバイパスするものだ。

セキュリティ企業Socketのブラッド・アーキン氏は2026年6月23日の公開記事で、構造的な現実を指摘している。AIエージェントは、セキュリティスキャナーが監視していない環境にパッケージを取り込み、セキュリティチームが検知する前に依存関係を解決してしまう。しかも、それは人間のレビュープロセスでは到底追いつけない規模と速度で行われる。

その実害は、2026年のサプライチェーンインシデントの記録に明確に現れている。Phoenix Securityの2026年サプライチェーンレポートによると、2026年上半期だけで、2025年全体と比較して2.6倍以上の攻撃キャンペーン数、および4.5倍以上のパッケージ侵害数が記録されている。AIコーディングエージェントは、攻撃の標的であると同時に、意図せぬ媒介者として、この傾向を加速させていると報告されている。

長年、オープンソースのサプライチェーン攻撃に対する主な防御策は、開発者による「立ち止まり」だった。人間であれば、パッケージのダウンロード数を確認したり、メンテナーの履歴を検証したり、見慣れない名前に疑問を持ったりしてからインストールを実行する。しかし、AIコーディングエージェントはそうした検証を行わない。エージェントは開発の摩擦を減らし、ビルドを迅速に進めるために設計されているため、見慣れないパッケージ名であってもそのまま依存関係を解決して処理を進めてしまう。この効率性の追求こそが、攻撃者にとっての脆弱性となっている。

■AIエージェントを標的に設計される悪意あるパッケージ

攻撃者がこの新たな標的に適応している明確な証拠として、ReversingLabsが調査した「PromptMink」キャンペーンが挙げられる。このキャンペーンは、暗号資産やフィンテックの開発者を標的とする北朝鮮の脅威グループ「Famous Chollima」によるものとされている。

少なくとも2025年9月から確認されているこのキャンペーンは、人気ライブラリに似た名前を騙る従来の「タイポスクワッティング」にとどまらない。PromptMinkは、ReversingLabsが「LLM最適化（LLMO）の悪用と知識注入」と呼ぶ手法を用いた。これは、人間の開発者ではなく、依存関係を解決する大規模言語モデル（LLM）に対して信頼性が高く見えるように、パッケージのREADMEファイルを巧妙に設計する手法である。

おとりとして用意されたパッケージ「@solana-launchpad/sdk」には、認証情報の窃取や、持続的なリモートアクセスのためのSSHキー配置、データのアーカイブなどを行うインフォスティーラーを含む悪意ある依存関係チェーンが仕込まれていた。攻撃者は検出を免れるために複数の悪意ある依存関係を切り替え、npm、PyPI、Rustへと拡大し、最終的にはコンパイル済みのRustペイロード（NAPI-RS経由）に移行して検知を困難にさせた。

このキャンペーンが実際にAIエージェントに到達していたことは、2026年1月に確認された。Solanaのハッカソン向けに開発された正規のプロジェクトに、この「@solana-launchpad/sdk」が依存関係として含まれているのが見つかったのだ。リポジトリの履歴を確認すると、この依存関係は「Claude Opus」が共同作成者として記録されたコミットによって追加されていた。

ReversingLabsのチームは、「これにより、手法がソーシャルエンジニアリングから、LLM最適化の悪用と知識注入の組み合わせへと変化した。その目的は、特定のLLMコーディングエージェントが作業しているプロジェクトにおいて、ドキュメントを可能な限り信頼性が高く適切なものに見せることで、LLMが悪意あるパッケージを推奨するように仕向けることだ」と結論づけている。

■スロップスクワッティング：AIのハルシネーションを悪用した攻撃

AIエージェントを騙すためにおとりパッケージを設計する手法に加え、AIの欠陥である「ハルシネーション（幻覚）」を悪用した第2の攻撃手法も登場している。

AIコーディングエージェントは、実在しないパッケージ名を頻繁に提案する。USENIX Security 2025で発表された研究では、16の大規模言語モデルを対象に57万6,000件のサンプルをテストしたところ、AIが生成したパッケージ推奨の約19.7%がレジストリに存在しないパッケージを参照していた。これらはレジストリの確認ではなく、学習データの統計的パターンに基づいてモデルが「捏造」したものだ。

Aikido Securityの研究者チャーリー・エリクセン氏は、この攻撃手法を「スロップスクワッティング（slopsquatting）」と名付けた。開発者がパッケージ名を打ち間違えることを期待する従来のタイポスクワッティングとは異なり、スロップスクワッティングは、AIエージェントが特定の名前を継続的にハルシネーションすることを利用する。攻撃者はそのハルシネーションされた名前を先回りして登録し、悪意あるペイロードを仕込むだけでよい。

スロップスクワッティングを構造的に危険にしているのは、AIのハルシネーションの予測可能性だ。研究者が同一のプロンプトを10回ずつ実行したところ、ハルシネーションされたパッケージ名の43%が、すべての実行において同一の名前で生成された。攻撃者は、人気のあるモデルに対して数十個のプロンプトを実行し、一貫して出現する名前を特定して、誰よりも先に登録すればよいことになる。

2026年1月、エリクセン氏は「react-codeshift」という実在しないnpmパッケージを登録した。これは、言語モデルが「jscodeshift」と「react-codemod」という2つの実在するツールを混同して生成した名前だった。彼が防御のためにその名前を確保する前に、このハルシネーションされた参照は、AIが生成したエージェントのスキルファイルを介して、すでに237個のGitHubリポジトリに拡散していた。登録直後から、自律エージェントによるダウンロードの試みが毎日記録されたという。

エリクセン氏は、「これはハルシネーションだったが、237のリポジトリに拡散し、実際のダウンロード試行を発生させた。これが攻撃経路にならなかった唯一の理由は、私が先にその名前を確保したからだ」と述べている。従来のタイポスクワッティング対策である「既存パッケージと類似した名前の衝突検知」は、スロップスクワッティングに対しては機能しない。ハルシネーションされた名前は完全に新しい文字列であるため、衝突として検知されないからだ。

■クラインジェクション：GitHubのIssueから500万人の開発者への攻撃へ

2026年2月に開示された「クラインジェクション（Clinejection）」インシデントは、CI/CDパイプラインに統合されたAIエージェントが、個々の開発者のマシンを超えてリスクを増幅させる様子を示している。

2026年2月9日、セキュリティ研究者のアドナン・カーン氏は、AIコーディングツール「Cline」のGitHubリポジトリにおける脆弱性チェーンを開示したが、Clineは2025年12月に、GitHub Issueに自動返信するためのAI駆動型Issueトリアージワークフローを追加していた。このワークフローは、書き込み権限のないユーザーを含むすべてのGitHubユーザーがトリガーできるよう設定されており、さらにエージェントに対してランナー上での任意のコード実行権限を与えていた。

攻撃者が指示を埋め込んだGitHub Issueのタイトルを作成すると、エージェントを騙して攻撃者が制御するコミットから「npm install」を実行させ、悪意あるプレインストールスクリプトを実行させることが可能だった。そこから、キャッシュ汚染技術を用いて、低権限ワークフローと高権限ワークフローの間で共有されているキャッシュを悪用し、最終的にリリースパイプラインからnpmやVS Code Marketplaceなどの公開用認証情報を流出させることができた。

公開から8日後、認証情報のローテーション中に一部のトークンが適切に失効されていなかった隙を突き、何者かが不正な「cline@2.3.0」をnpmに公開した。この修正版は、8時間の間にアップデートを行ったすべての開発者のマシンに、コマンド実行権限とファイルシステムアクセス権を持つオープンソースAIエージェント「OpenClaw」をインストールした。Clineのユーザー数は500万人を超えている。

Snykの研究者スティーブン・トームズ氏が指摘するように、この攻撃には斬新な技術は使われておらず、間接プロンプトインジェクションやキャッシュ汚染、認証情報の管理不備といった既知の脆弱性を組み合わせ、1つのGitHub Issueをトリガーとして実行されたものだった。侵入経路はコードではなく、自然言語だったのだ。

トームズ氏は、「プロンプトインジェクションのスキャナーはキャッシュ汚染を検知できない。また、CI/CDのセキュリティガイドラインも、自然言語が攻撃経路になることを想定していない」と指摘している。

■ポストインストールフックの仕組みと脅威

上述したサプライチェーン攻撃はすべて、npmエコシステムの構造的機能である「ポストインストールフック（postinstall hook）」を介してペイロードを実行している。

開発者やCI/CDパイプラインが「npm install」を実行すると、npmはパッケージの「package.json」に定義されたポストインストールまたはプレインストールスクリプトを自動的に実行する。これはアプリケーションコードが実行される前、かつ静的分析ツールやソフトウェア構成分析（SCA）ツールが検査を行う前に実行される。このフックは開発者プロセスと同じ権限で実行されるため、ローカル環境に保存されているAPIキー、クラウド認証情報、SSHキー、CI/CDトークンなどにアクセスできてしまう。

「npm install --ignore-scripts」を実行すれば、多くのパッケージでこの実行をブロックできる。しかし、ネイティブ拡張（binding.gyp）を使用してこのフラグを回避する手法など、既知のバイパス方法が存在する。また、脆弱性「CVE-2025-69263」では、git依存関係内の悪意ある「.npmrc」がgitバイナリ自体を上書きできることが示されている。そのため、名前をCVEデータベースと照合するだけでなく、パッケージがコードレベルで実際に何を行うかを監視する「挙動検知」が構造的な解決策となる。フラグによる制御は部分的な対策にすぎない。

これこそが、Socketが提供している技術である。彼らは、脆弱性（CVE）が公表されるのを待つのではなく、オープンソースの依存関係がコードベースに入る前にその挙動を分析するアプローチをとっている。

■CISAなどの政府機関による警告

2026年5月1日、CISA（米国土安全保障省サイバーセキュリティ・インフラセキュリティ庁）、NSA（米国家安全保障局）、およびファイブ・アイズ（Five Eyes）のパートナー機関（オーストラリア、カナダ、ニュージーランド、英国のサイバーセキュリティ機関）は、共同で「Careful Adoption of Agentic AI Services（自律型AIサービスの慎重な導入）」と題したガイドラインを公開した。これは、エージェント型AIの導入に特化した初の政府間共同セキュリティガイダンスである。

このガイドラインでは、本記事で説明した攻撃手法について明示的に言及している。「ツールの説明が不十分であったり、意図的に誤解を招くものであったりすると、エージェントが信頼性の低いツールを選択する原因となり、説得力のある説明を持つツールが選ばれやすくなる」と指摘しており、これはLLMがドキュメントを通じてソーシャルエンジニアリングされ得るという、PromptMinkがすでに悪用していた仕組みを直接認めたものだ。

ガイドラインでは、組織が承認済みのサードパーティコンポーネントの信頼できるレジストリを維持すること、AIエージェントの利用を許可リストに登録されたツールとバージョンに制限すること、および影響の大きいアクションを実行する前に人間の承認を求めることを推奨している。また、プロンプトインジェクションをエージェント導入における「最も持続的で解決が困難な脅威」と位置づけ、単一 of 対策だけでは不十分であるとしている。

ガイダンスのトーンは慎重であり、「セキュリティの実践、評価方法、および基準が成熟するまでは、組織はエージェント型AIシステムが予期しない動作をする可能性があると想定し、効率性の向上よりも回復力、可逆性、およびリスク抑制を優先して導入を計画すべきである」としている。

■開発者とチームが取るべき5つの対策

セキュリティ研究者やCISAなどのガイドラインは、攻撃手法が進化する中でも有効な複数の対策を提示している。

1. AIエージェントが提案するパッケージを別枠でレビューする：AIエージェントが自律的に提案またはインストールするすべての依存関係は、パブリッシャー、バージョン履歴、および過渡的な依存関係がレビューされるまで、デフォルトで「信頼できないもの」として扱うべきである。人間が作成したコードと同様の基準を適用する必要があるが、エージェントによる追加は人間のレビューをすり抜けてしまうことが多い。

2. CI/CDレベルでレジストリポリシーを強制する：開発者の端末だけに適用される対策では、CI/CDパイプラインやサンドボックス環境でエージェントが導入するパッケージを防ぐことはできない。Socket Firewallや、2026年5月22日に一般提供が開始されたnpmの段階的公開機能（staged publishing）などのレジストリレベルの制御により、導入経路に関わらずポリシーを強制する必要がある。

3. 機密性の高い環境では、エージェントの動作を事前承認された依存関係リストに制限する：承認済みの許可リストにないパッケージをインストールできないように設定されたAIエージェントであれば、LLMが何を提案しようとも悪意あるパッケージをインストールすることはできない。CISAのガイドラインでも、影響の大きいアクションに対する人間の承認要件としてこれが言及されている。

4. SBOM（ソフトウェア部品表）を活用する：SBOMを導入することで、エージェントが導入した依存関係を事後的に監査可能にする。エージェントが何をインストールしたかを可視化できなければ、インシデント発生時に迅速に対応することはできない。

5. 挙動検知を導入する：従来のソフトウェア構成分析ツールは、依存関係の名前をCVEデータベースと照合するが、CVEは脆弱性が開示された後にしか登録されない。2026年に発生したTanStack、Mastra、Clineへのサプライチェーン攻撃では、攻撃時点でCVEは存在しなかった。パッケージの名前ではなく、コードレベルで実際に何を行うかを検証する挙動分析ツールを導入することで、CVEが登録される前に不審な挙動を検知できる。

ブラッド・アーキン氏が指摘したように、現在の開発環境において、コードはセキュリティチームが把握している場所以外からも侵入している。ビルドパイプラインの防御は比較的容易だが、開発者の端末は盲点となりやすい。そして、エージェント環境は最も急速に拡大している隙であり、現時点で多くの組織が攻撃対象領域として認識できていない領域である。

■注目ポイントQ&A

●GitHub CopilotやCursor、Claude CodeなどのAIツールは、パッケージを提案・インストールする前に自動で検証してくれないのですか？

ほとんどのAIコーディングエージェントは、提案するパッケージが実在するか、信頼できるパブリッシャーによって維持されているか、あるいは悪意ある挙動が報告されていないかをリアルタイムで検証しません。エージェントは学習データの統計的パターンに基づいてパッケージ名を生成するため、実在しないパッケージを提案する「ハルシネーション」が発生します。研究では約5回に1回の割合で実在しないパッケージが提案されることが示されており、攻撃者はこの隙を狙って実在しない名前を先回りして登録しています。一部のツールではリアルタイム検証機能の追加が始まっていますが、リスクを完全に排除することはできていません。

●スロップスクワッティング（slopsquatting）とは何ですか？タイポスクワッティングとはどう違うのですか？

タイポスクワッティングは、人間がパッケージ名を打ち間違えること（例：requestsをreqeustsと誤入力する）を狙う手法です。これに対し、スロップスクワッティングは、AIモデルが一貫して発生させる「ハルシネーション（実在しないパッケージ名の生成）」を狙う手法です。AIのハルシネーションには高い再現性があり、同じプロンプトに対して同じ実在しない名前を生成する傾向があります。攻撃者は人気モデルのハルシネーションパターンを分析し、生成されやすい実在しない名前を先回りしてレジストリに登録することで、AIエージェントに悪意あるパッケージを自動でインストールさせます。衝突検知などの従来のタイポスクワッティング対策では防ぐことができません。

●AIエージェントが悪意あるパッケージをコードベースに導入したかどうかを、どのように確認すればよいですか？

AI支援ツールを使用したセッション中に追加された依存関係マニフェストやロックファイルを確認し、Socketなどの挙動分析ツールを用いて検証してください。公開日が極端に新しいパッケージや、開発者が把握していないメンテナー、ダウンロード数が不自然に少ないパッケージがないかを確認します。また、CI/CDパイプラインのログを監査し、人間ではなくエージェントのワークフローによって実行された「npm install」や「pip install」のコマンドがないかをチェックすることも重要です。CISAなどのガイドラインでは、AIエージェントの設定ファイル（CLAUDE.mdや.cursorrulesなど）に不審な指示が埋め込まれていないか確認することも推奨されています。

●米国政府などの公的機関は、AIエージェントとサプライチェーンのリスクについてどのような対策を推奨していますか？

CISA、NSA、およびファイブ・アイズが2026年5月に公開した共同ガイドラインでは、AIコーディングエージェントをデフォルトで「信頼できないコンポーネント」として扱うことを推奨しています。具体的には、事前承認されたサードパーティコンポーネントの信頼できるレジストリを維持し、エージェントの動作をそのリスト内に制限すること、新しい依存関係のインストールなどの影響が大きいアクションを実行する前に人間の承認を必須とすること、エージェントに必要最小限の権限のみを与えること、およびエージェントのすべてのやり取りを監視・ログ記録することが挙げられています。ガイドラインでは、効率性よりもシステムの回復力やリスク抑制を優先すべきであると強調されています。

元記事: AI Coding Agents Skip Package Verification, and Attackers Are Exploiting It