その仕組みは驚くほどシンプルだ。コーディングアシスタントは、もっともらしく聞こえるが実在しないオープンソースパッケージを日常的に創作し、攻撃者はそれらの名前をマルウェアを仕込んで事前登録する。これらは実在するライブラリのスペルミスではないため、タイポスクワッティングに対抗して10年かけて構築されたレジストリ防御機能はほとんど役に立たない。この脅威はランダムではなく体系的なものだ。

これが大規模で危険なのは、ハルシネーションの決定論的性質による。類似のデータで訓練されたモデルは同じ架空の名前を創作する傾向があるため、単一の汚染されたパッケージが、AIが'推奨した'依存関係を一切監査しない数万人の開発者に提示される可能性がある。報告されているハルシネーション率は50%から82%に及び、品質問題を悪用可能な配布チャネルに変える。脆弱性のライフスパンの長期化と相まって、悪意あるコードは本番環境で数か月間休眠状態になり得る。

グローバル経営陣にとっての戦略的転換は、信頼が開発者からモデルに移行したことだ。従来の安全な開発トレーニングは、人間が各ライブラリを選択することを前提としていた。今や選択レイヤーは確率的でゲーム可能だ。AI支援エンジニアリングに大きく依存する企業(ほぼすべての企業がそうだ)は、ガバナンスを更新することなく攻撃面を事実上拡大している。

推奨される対策は具体的だ。依存関係の許可リストとロックファイルを義務付け、事前の検証なしにパッケージがビルドに入らないようにする。Snyk、Socket、JFrogなどのソフトウェア構成分析を導入し、新規公開または低評価のパッケージにフラグを立て、Sigstore署名などの来歴チェックを要求する。CISOはAIが提案する依存関係をデフォルトで信頼できない入力として扱い、インストール前にCI/CDに検証ゲートを追加すべきだ。

ベンダーにとっての機会もある。npmやPyPIなどのレジストリ、およびGitHub Copilot、Anthropic、OpenAIなどのアシスタント製作者は、生成されたパッケージ名をリアルタイムで実際のレジストリと照合するよう圧力を受けることになる。信頼できる依存関係検証を最初に提供するプラットフォームは、責任を差別化要因に変える。投資家は、業界が価格設定を始めたばかりのリスクの短期的受益者として、サプライチェーンセキュリティのスタートアップに注目すべきだ。