AIのコードを誰が検証するのか？ オープンソースの取り込みが直面する「規模」という課題

ActiveState プロダクト責任者、ジョニー・リベラ

先週開催されたBlack Hatの展示会場で、私たちのチームがアプリケーションセキュリティ責任者、プラットフォームエンジニア、CISOと交わしたほぼすべての会話の中で、ある質問が繰り返し挙がりました。「実際にAIのコードを審査しているのは誰なのか？」

開発者によるAIコーディングツールの採用は衰える気配がありません。生産性の向上は確実であり、オープンソースソフトウェアは依然として現代のエンタープライズアプリケーションの基盤となっています。しかし、AIコーディングアシスタントがサードパーティの依存関係の候補をミリ秒単位で自動補完する中、企業のセキュリティチームとオープンソースのメンテナーは共通の運用上の課題に直面しています。それは、コード生成の速度が、従来の取り込み後のレビューを完全に凌駕してしまったということです。

検証されていない、あるいは誤った依存関係がマシンの速度でコードベースに流入すると、コミット後のソフトウェア構成分析（SCA）スキャンではそのペースについていくのが困難になります。

このパイプラインのセキュリティを確保することは、開発者の作業を遅らせたり、オープンソースの利用を制限したりすることを意味するわけではありません。インポートによってビルドがトリガーされる前の、選択の段階で、環境に何が取り込まれるかを管理することが求められます。

「スロープスクワッティング」と機械による取り込みの仕組み

大規模言語モデル（LLM）は、リアルタイムのパッケージレジストリ検証ではなく、統計的な確率や過去のコードパターンに基づいてソフトウェアライブラリを推奨します。

モデルがPyPIやnpmに存在しないパッケージ名を提案すると、「スロープスクワッティング」（またはAIパッケージ幻覚の悪用）として知られるサプライチェーンの脆弱性が生じます。

この脆弱性ベクトルの規模は、50万件以上のコードサンプルを対象に16の人気コード生成モデルを分析したUSENIX Securityの研究で浮き彫りになりました：

• AIが提案したパッケージ名のうち、一定割合がパブリックレジストリに存在しないことが判明しました。

• 実際に存在するパッケージに解決される推奨依存関係のうち、ほぼ半数が既知のCVEや古いリリースを含んでいる。

攻撃者は、公開されているLLMの出力パターンや開発者のコードリポジトリを日常的に監視し、こうした「幻覚」によるパッケージ名を特定しています。特定されると、攻撃者はそのダミー名をPyPIやnpmに登録し、悪意のあるペイロードをアップロードして、自動化された開発環境やCI/CDビルダーがそれを取得するのを待ちます。

 
     [開発者のワークスペース] ---> [AIアシスタントによるパッケージ名の自動補完] 
                                    |
                                    v
                  [レジストリにパッケージ名が存在しない]
                                    |
                                    v
          [攻撃者がペイロード付きでPyPI/npmに名前を登録]
                                    |
                                    v
          [CI/CDパイプラインがパッケージを取得] ---> [侵害されたビルド]

この攻撃ベクトルは、実際の環境でのデプロイにおいて活発に確認されています。2026年初頭、セキュリティ研究者は、単一のコミット内に含まれる47のAI生成エージェントスキルに由来する、1つの「幻覚」npmパッケージ名（react-codeshift）を追跡しました。

この「幻覚」は、あるエンジニアが「人間が明示的にこれを選択したことは一度もない」ことに気付くまで、フォークを通じて有機的に拡散し、230以上のリポジトリに広がりました。

この問題は、開発者の悪意によるものではなく、取り込み制御が完全に欠如していたことに起因するものでした。

オープンソースレビューにおける「摩擦の増幅要因」

企業内部における取り込みの課題は、より広範なオープンソースエコシステムに直接的な影響を及ぼします。企業ネットワーク内で検証されていない依存関係の提案を生成しているのと同じAIアシスタントが、コミュニティが管理するリポジトリに送信される自動化されたプルリクエストも生成しています。

この膨大な量の自動貢献は、人間のメンテナーに前例のない負担を強いています：

• AI ポリシー間の矛盾：Kubernetes、Linux カーネル、LLVM、Godot などの主要プロジェクトは、AI 支援による貢献に関して、互いに異なるポリシーを公表しています。AI 生成コードを全面的に禁止するプロジェクトがある一方で、人間の貢献者が追加されたすべての行に対して完全な責任を負う場合にのみ許可するプロジェクトもあります。

• 欠陥密度の増加：CodeRabbitによる470件のオープンソースプルリクエストの調査によると、AIが共同作成した貢献は、表面的には問題ないように見えても、人間が作成したコードに比べて70％多くの欠陥を含んでいることが判明しました。

誤った出力を生成したパッケージや脆弱性のあるパッケージが企業の取り込みプロセスを通り抜けると、それらは必然的に上流のオープンソースPRに波及し、ボランティアのメンテナーは、人間が意図的に評価していない依存関係を検証するために何時間も費やすことを余儀なくされます。

スピード対検証：ガバナンスのギャップ

Kusariの『Application Security in Practice』レポートによる最近のテレメトリデータは、ツールの導入が取り込み制御をどれほど大きく上回っているかを示しています：

従来のアプリケーションセキュリティ（AppSec）ワークフローは、コードが記述された後、あるいはプルリクエストが作成された後にスキャンを行うことに依存しています。コードがマシンの速度で生成される場合、後期段階でのアラートは単にバックログのノイズを生み出し、エンジニアはそれを無視してしまいます。

選択の時点でパイプラインを保護する

LLMの幻覚発生率がゼロになるのを待つことは、AppSec戦略とは言えません。核心となる問題はモデルの精度ではなく、速度です。出力を犠牲にすることなく開発パイプラインを保護するため、セキュリティチームやプラットフォームチームは、防御をIDEの「左側」へと移行させています：

1. レジストリからの直接取得を制限する：コード補完中に、開発者のワークステーションやAIエージェントが、検証済みのパブリックエンドポイントに対して直接クエリを実行できないようにブロックします。

2. AIが提案した依存関係を隔離する：新たに導入された依存関係を隔離されたサンドボックスにルーティングし、主要ブランチへの取り込みを許可する前に、到達可能性および脆弱性の自動分析を行う。

3. 取り込みゲートウェイの管理： 事後対応的なCVEの集計から、事前対応的なソースのキュレーションへと移行し 、AIモデルが推奨するすべてのパッケージが、悪意のあるタイポスクワットやスロップスクワットの標的に対して事前に審査済みであることを保証します。

この取り込みレイヤーこそが、ActiveStateの「Secure Open Source Library」および「Curated Catalog」が機能する場所です。エンタープライズグレードの取り込みゲートウェイとして設計されたActiveStateは、事前に審査され、継続的に修正されたオープンソースパッケージを、開発者のワークステーション、CI/CDパイプライン、およびAIエージェント環境に直接提供します。

パブリックパッケージレジストリと開発者ツールの間に位置するキュレーション済みカタログにより、パッケージ選択の段階で、AIによる誤った推奨によるリスクを確実に遮断します。

ガバナンスの適用された取り込みソース上で運用されるエンタープライズチームは、取り込み段階においてスロープスクワッティングの攻撃経路を排除し、開発者にAIアシスタントを無効化させることなく、CVEへの全体的な曝露リスクを約95％削減します。

結論

AIコーディングツールを無効化することは、現実的でもなければ競争力にもつながりません。しかし、ソフトウェアサプライチェーンの取り込みルールを更新せずに、AIの統合を単に開発者の生産性指標としてのみ扱うことは、本番環境のビルドを自動化された侵害の危険にさらすことになります。

現代の開発パイプラインを保護するには、開発者やエージェントが選択したすべてのパッケージが、ビルドに組み込まれる前にデフォルトでガバナンスの対象となるよう確保する必要があります。

ActiveStateがお客様のオープンソースアプリケーションのセキュリティ確保にどのように貢献できるかご興味をお持ちの方は、今すぐデモをご予約ください。

著者について：

ジョニー・リベラは、サイバーセキュリティ、デジタルヘルスケアソリューション、開発者向けツールといった分野でキャリアを積んできたプロダクトリーダーです。中学2年生の元気いっぱいの娘を持つ「演劇パパ」であり、18年前に『World of Warcraft』で出会った最愛のパートナーと結婚して18年になります。 

ActiveStateによる提供・執筆。