今回のHelp Net Securityのインタビューでは、Zentera SystemsのCEOであるJaushin Lee博士に、AIサプライチェーンリスクがどこで顕在化しているかを伺いました。同氏によれば、実際のインシデントの大半は今も開発ワークフローやオープンソースのパッケージリポジトリで発生しており、汚染されたモデルの重みや侵害されたMCPサーバーは依然として研究デモの域にとどまっているといいます。
同氏は、なぜセグメンテーションがツール導入よりも投資対効果の高いリスク低減策となるのか、モデルを自前でホストする方法にはどのような限界があるのか、そして半導体業界の分離手法のうちソフトウェアチームが見習うべきものはどれかについて解説します。さらに、かつて信じていたものの今では手放したセキュリティ上の考え方についても語ってくれました。
かつてサプライチェーンリスクといえば、依存関係やソフトウェア部品表（SBOM）を指していました。今ではそこに、モデルの重み、モデルコンテキストプロトコル（MCP）サーバー、エージェントツール、ベクトルストアも含まれます。このうち、実際に顧客企業でインシデントを引き起こしているのはどれで、カンファレンスの話題にはなってもインシデントには至っていないのはどれでしょうか。
現時点で、実際に発生しているサプライチェーンインシデントの大半は、基本的な開発ワークフローとオープンソースパッケージリポジトリで起きています。操作されたモデルの重み、汚染されたベクトルストア、侵害されたMCPサーバーといった目新しい攻撃対象領域も構造的な脅威として実在してはいますが、今のところ主にセキュリティ研究やカンファレンスのデモの中にとどまっています。
とはいえ、こうした新興の攻撃ベクトルがいつまでも理論上のものにとどまると考えるのは危険です。実際に悪用されるキャンペーンが一つ発見されるだけで、概念実証段階の脅威は一夜にして大きなインシデントへと姿を変えてしまいます。
すでに、開発者を直接狙ったAIネイティブなサプライチェーン攻撃も確認されています。その典型例が、現在も活動中の「Phantom Raven」キャンペーンです。攻撃者は、生成AIツールが「vibeコーディング」セッション中に実在しないソフトウェアパッケージ名を幻覚（ハルシネーション）として生成する様子を観察しています。そのうえで、幻覚によって生成されたパッケージ名を意図的に公開リポジトリに登録し、悪意あるペイロードを仕込んでおくのです。監視の行き届いていない開発者のスクリプトやAIエージェントが、推奨された依存パッケージを自動的に取得してしまうと、ビルドパイプラインに気づかぬうちにマルウェアがインストールされてしまいます。
モデルの重みやMCPサーバーへの注視は引き続き必要ですが、現時点で攻撃者が実際に悪用しているのは、単純な人間の信頼心とパッケージ管理の習慣であるということを認識しておくべきです。
もしある企業が今年度に一つのプロジェクトにしか予算を投じられないとしたら、開発環境のセグメンテーションとAIツールの計装（インストゥルメンテーション）のどちらを優先すべきでしょうか。1ドルあたりのリスク低減効果が高いのはどちらで、その答えが変わるとすればどのような条件のときでしょうか。
環境のセグメンテーションのほうが、1ドルあたりのリスク低減効果は明らかに高くなります。セグメンテーションは、「未知の未知（unknown unknowns）」に対する構造的な封じ込め層を提供してくれます。開発者がどんな新しいAIツールを使おうと、エージェントがどんな未知のエクスプロイトを用いようと関係ありません。周囲のネットワークが、そのマシンやプロセスから隣接する企業資産への到達を防いでいれば、被害は厳密に封じ込められます。
とはいえ、現場の実情によって優先順位が変わることも少なくありません。適切な環境セグメンテーションには、綿密なアーキテクチャ設計と部門横断の合意形成が必要であり、それには時間がかかります。もし組織がAIネイティブな開発パイプラインを運用していたり、ガバナンス・リスク・コンプライアンス（GRC)監査の差し迫った圧力に直面していたりする場合、経営層はまず専用のAIセッション管理・可視化ツールを求めるかもしれません。
私の答えを根本的に変えるとすれば、それはデータの機密性です。極めて機密性の高い知的財産、高額の金融記録、あるいは境界の外に絶対に出してはならない厳格な規制対象データを扱う環境であれば、環境のセグメンテーションを最優先すべきです。一度のデータ漏えいが致命的なコンプライアンス違反につながる状況では、ツールの計装だけに頼るわけにはいきません。
モデルの自前ホスティングは、堅実な選択肢として語られがちです。その前提が実際には成り立たなくなるのはどのような場合でしょうか。
モデルを自前でホストすることは、データがサードパーティのSaaSプロバイダーに送信されるのを防ぐという点では優れた一歩です。しかし、それだけでセキュリティ問題が解決すると考えるのは誤った安心感にすぎません。自前ホスティングはリスクをなくすわけではなく、単にその運用責任のすべてを社内チームに移すだけなのです。
この前提が崩れるのは、モデルをローカルでホストしても、ローカルのAIエージェントが自社ネットワークやインターネット上で何を実行できるかを制御することにはならないためです。自前ホストのモデルとやり取りするエージェントであっても、実行環境に境界が設けられていなければ、悪意あるローカルコマンドを実行したり、検証されていない外部の依存関係を取得したり、認証情報を漏えいさせたりする可能性は残ります。
さらに、自前ホスティングは運用面のハードルを引き上げます。モデル基盤の脆弱性へのパッチ適用、悪用の監視、デプロイのレッドチーミングといった、本来であれば商用クラウドプロバイダーが代わりに担ってくれるはずの作業を、すべて自社チームが責任を負うことになります。エージェント周りに厳格なローカルサンドボックスを設けずにモデルを自前ホストしても、サプライチェーン上のリスクは公開APIを利用する場合とまったく変わりません。
半導体業界の顧客は、ほとんどどの業界よりも厳重に設計データを守っています。そうした業界の慣行のうち、一般的なソフトウェア企業が見習うべきものはどれで、逆にお金の無駄になるものはどれでしょうか。
ソフトウェア企業は、半導体業界がプロジェクト単位のエンクレーブや「チェンバリング（区画化）」に対して取っているアプローチを、今すぐにでも取り入れるべきです。チップ設計の現場では、特定のプロジェクトのワークロードをソフトウェア定義のエンクレーブに分離し、厳格な送信制御、明示的な認可、そして包括的なセッションログの記録を徹底しています。同じ考え方をソフトウェア開発に適用すれば、プロジェクトAに携わるAIエージェントや開発者が、プロジェクトBの独自コードリポジトリに決してアクセス・閲覧・混入できないようにすることができます。
一方で、ソフトウェア企業が見習うべきではないのは、開発グループごとにエアギャップで物理的に分離したハードウェアネットワークを構築するという、半導体業界の従来からの慣行です。チームやクライアント案件ごとに別々の物理ネットワークを構築することは、法外にコストがかかるうえ運用の柔軟性を欠き、現代のクラウドネイティブなワークフローには完全に不要です。
物理的なエアギャップの代わりに、ソフトウェアチームはそうした境界を仮想化すべきです。ソフトウェア定義のセグメンテーションを用いれば、単一の俊敏なデータセンターやクラウド環境を維持しながら、半導体大手が頼りにしているのとまったく同じ数学的なプロジェクト分離を実現できます。
5年前には有効だと信じていたものの、今ではもう勧めないセキュリティ対策はありますか。
5年前、私は特権アクセス管理を有効な戦略だと信じていました。認証情報をボールトに保管し、ID単位で最小権限を徹底すれば、資産は守られると考えていたのです。ゼロトラストの考え方は、その信念をすでに揺るがし始めていました。そこから得た教訓は、ネットワークアクセスに対する「常設された信頼」こそが本当の脆弱性であるということです。「誰がこの資産にアクセスする権限を持っているか」と「誰がこの資産にトラフィックを送信できるか」の間には、微妙ながら重要な違いがあります。前者はアプリケーション層の問題であり、後者はネットワーク層の問題です。そして、攻撃が先に進むかどうかを左右するのは後者なのです。
エージェントの登場が、私の中でこの論拠を決定づけました。ID単位の権限付与は、一時的に生成されては消えるエージェント群に対して十分な速さで作成することができず、しかもエージェントは正当に付与された権限すら悪用しかねません。権限はそもそも境界にはなり得なかったのです。今、本当に重要な制御とは、タスクと意図の範囲に絞り込んだ封じ込めにほかなりません。
翻訳元: https://www.helpnetsecurity.com/2026/08/25/jaushin-lee-ai-zentera-systems-supply-chain-risk/
