AIのコードを検証するのは誰か――オープンソース取り込みが直面する規模の課題

執筆者: Jonny Rivera（ActiveState プロダクト責任者）

先週のBlack Hatの会場で交わした会話の中で、AppSec担当者やプラットフォームエンジニア、CISOとのほぼすべての議論で共通して浮上した問いがあります。それは「AIが生成したコードを実際に検証しているのは誰なのか」というものです。

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

検証されていない、あるいは実在しない依存関係がマシン並みの速度でコードベースに入り込んだ場合、コミット後に行うソフトウェア構成分析(SCA)スキャンではとても追いつけません。

このパイプラインを保護するということは、開発者の手を止めたりオープンソースの利用を制限したりすることではありません。必要なのは、インポートがビルドを発火させるより前の「選定の時点」で、環境に入り込むものを統制することです。

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

大規模言語モデル(LLM)がソフトウェアライブラリを推薦する根拠は、統計的な確率や過去のコードパターンであり、リアルタイムのパッケージレジストリ検証ではありません。

モデルがPyPIやnpmに存在しないパッケージ名を提案してしまうと、スロップスクワッティング(AIによるパッケージ幻覚を悪用した攻撃)と呼ばれるサプライチェーンの脆弱性が生まれます。

この脆弱性ベクトルの規模の大きさは、16種の人気コード生成モデルを50万件以上のコードサンプルにわたって分析したUSENIX Securityの研究で明らかにされています。

• AIが提案したパッケージ名のうち、無視できない割合が公開レジストリに実在しない。

• 実在するパッケージに解決される提案依存関係についても、その半数近くが既知のCVEを含んでいるか、古いリリースである。

攻撃者は公開されているLLMの出力パターンや開発者のコードリポジトリを常時監視し、こうした実在しないパッケージ名を特定します。特定できれば、その架空の名前をPyPIやnpmに登録して悪意あるペイロードをアップロードし、自動化された開発環境やCI/CDビルダーがそれを取得するのを待ち構えるのです。

     [Developer Workspace] ---> [AI Assistant Auto-completes Package Name] 
                                    |
                                    v
                  [Package Name Does Not Exist in Registry]
                                    |
                                    v
          [Attacker Registers Name on PyPI/npm with Payload]
                                    |
                                    v
          [CI/CD Pipeline Fetches Package] ---> [Compromised Build]

このベクトルは実際の運用環境でも観測されています。2026年初頭、セキュリティ研究者たちは、単一のコミットに含まれる47個のAI生成エージェントスキルに由来する、実在しない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 and Curated Catalogが機能する場所です。エンタープライズグレードの取り込みゲートウェイとして動作するよう設計されており、ActiveStateは事前検証済みで継続的に修復されたオープンソースパッケージを、開発者のワークステーション、CI/CDパイプライン、AIエージェント環境に直接届けます。

公開パッケージレジストリと開発者ツールの間に位置することで、キュレーションされたカタログは、実在しないパッケージのリスクを選定境界で確実に遮断します。

統制された取り込みソースを運用する企業チームは、取り込み段階でスロップスクワッティングのベクトルを排除し、開発者にAIアシスタントの利用を止めさせることなく、全体のCVE露出をおよそ95%削減できます。

結論

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

現代の開発パイプラインを保護するには、開発者であれエージェントであれ、選定されるすべてのパッケージがビルドに到達する前に、デフォルトで統制されている状態を確保する必要があります。

ActiveStateがオープンソースアプリケーションの保護にどう役立つか関心がある方は、今すぐデモを予約してください。

著者について:

Jonny Riveraは、サイバーセキュリティ、デジタルヘルスケアソリューション、開発者向けツールにまたがるキャリアを持つプロダクトリーダーです。中学2年生の演劇好きな子どもの誇り高き「シアターダッド」であり、World of Warcraftで出会った最愛の人と結婚して18年になります。