AI 開発の普及で拡大するサプライ チェーン攻撃とは？最新事例 (LiteLLM、Shai-Hulud) と防御策

近年、GitHub Copilot や社内 LLM など、AI を活用した開発が急速に広がっています。開発効率が向上する一方で、企業のセキュリティ部門が直面しているのは、これまでとは本質的に異なるサプライ チェーン リスクです。

すでに海外では、AI 開発で利用される開発基盤が侵害され、正規のソフトウェア配布経路そのものが攻撃に悪用される事例も報告されています。

これらのリスクは AI 特有の攻撃手法によるものではなく、 AI 開発で利用される OSS、モデル、CI/CD、開発者環境といった 「ソフトウェア サプライ チェーンそのもの」が攻撃対象となっている点が本質です。

AI 開発の普及により、これらの「信頼すべき対象」が急速に増加していることが、リスク拡大の背景にあります。従来の「脆弱性管理」だけでは対応しきれない、AI 開発の普及に伴うリスク構造が、すでに現場で問題になり始めています。

AI 開発で利用される技術スタックに広がるサプライ チェーン攻撃

サプライ チェーン攻撃は従来、

  • OSS パッケージを改ざん
  • 開発者にインストールさせる

といった手法が主流でした。

しかし現在は、CI/CD、開発基盤、さらには AI 開発で利用される OSS やモデルなど、 ソフトウェア サプライ チェーン全体が攻撃対象へと拡大しています。

事例 1: LiteLLM 侵害 (従来型の延長)

JFrog 社の調査※1 では、AI 開発で利用される LiteLLM の PyPI パッケージが侵害され、一部のバージョンに悪意あるコードが含まれていたことが確認されています。

攻撃者は正規パッケージの配布経路を悪用し、インストール時に認証情報の窃取などを狙うコードを実行させる仕組みを組み込んでいました。

「パッケージを信頼できるか」、すなわち外部から取得したソフトウェアを安全と前提して利用してよいのかという、従来からの課題の延長にあります。

事例 2: Shai-Hulud (自己拡散型攻撃)

さらに重大なのが、JFrog 社が報告した Shai-Hulud サプライ チェーン攻撃です。

この攻撃では、以下のような事象が確認されています。

  • npm / PyPI 両方にまたがって侵害
  • 300 件以上のパッケージが影響 (2026年 5月 19日時点の分析※2)
  • 開発環境や CI/CD 上でコード実行
  • クラウド、CI、GitHub の認証情報を窃取
  • 盗んだ権限でさらにパッケージを汚染

▶ 最大の特徴: 自己増殖 (ワーム化)

この攻撃の本質は以下です:

  • 感染した開発環境が次の感染源になる
  • 正規ユーザーの権限で攻撃が拡散
  • CI/CD パイプライン自体が攻撃媒体化

このように、従来のように一度の感染で終わる攻撃とは異なり、 感染した環境からさらに別のパッケージや開発環境へと攻撃が広がっていくことが特徴です。

例えば、侵害された開発環境で盗まれた認証情報を使って、 別のパッケージが不正に公開されると、そのパッケージを利用した他の開発者やシステムにも影響が及びます。

そのため、最初は一部の開発環境の問題であっても、 結果的に複数のプロジェクトや組織全体へ影響が広がる可能性があります。

事例 3: TanStack 侵害 (実際の開発基盤が攻撃経路に)

Shai-Hulud 攻撃は理論上のリスクではなく、実際の OSS プロジェクトにも影響を与えています。

JFrog 社の分析をもとに整理すると、この攻撃は以下のような流れで実行されます。

  • TanStack などの実在 OSS の CI/CD 環境を侵害
  • 正規のリリース ワークフローを悪用
  • 正規パッケージとしてマルウェア配布

さらに重要なのは、以下のような挙動です。

  • ビルドキャッシュが汚染され
  • 正常なビルド処理でマルウェアが復元

この事例が示すのは、「信頼されている OSS や CI/CD であっても、安全とは限らない」という現実です。

AI 開発の普及で顕在化した 3 つのリスク

AI 開発の普及に伴い顕在化しているサプライ チェーン リスクは、大きく 3 つに整理できます。

① OSS、依存関係の侵害

LiteLLM の事例が示す通り、

  • OSS ライブラリ
  • CI/CD ツール
  • DevOps コンポーネント

が連鎖的に侵害されることで、結果として開発環境やアプリケーション環境、 さらにはクラウド環境へと攻撃が波及します。

特に AI 開発で利用される OSS やツール群は依存関係が多く、 ひとつの侵害が広範囲へ波及しやすい点が特徴です。

② AI モデル (LLM) のサプライ チェーン リスク

AI 開発ではコードだけでなく、

  • モデル ファイル
  • 重みデータ
  • シリアライズ形式 (例: Pickle)

もサプライ チェーンの一部になります。

JFrog 社の発表でも、

  • ML モデルに悪意あるコードが含まれる可能性
  • モデル経由での組織内部侵入リスク

が指摘されています。

モデルは「ただのデータ」ではなく、実行可能な攻撃媒体です。

③ 可視化されない AI 開発コンポーネント (ガバナンス欠如)

企業内では、

  • Hugging Face からのモデル ダウンロード
  • 外部ライブラリの直接利用
  • 開発者単位で導入される AI 関連ツールや OSS コンポーネント

といったケースが増加しています。

しかしこれらは、従来の SBOM や OSS 管理では十分にカバーしきれない場合が多く、 管理の範囲外として扱われてしまうケースも少なくありません。

その結果、

  • どのモデルやツールが利用されているかを網羅的に把握できない
  • 安全性が十分に検証されていない
  • ライセンスや利用条件に関するリスク

といった「シャドー AI」の問題が発生します。

なぜ従来の DevSecOps だけではカバーしきれないのか

従来の DevSecOps は有効ですが、AI 開発の普及に伴い「管理対象」が増え、既存の枠組みだけでは抜け漏れが生まれやすくなっています。

既存のセキュリティ対策は主に以下にフォーカスしています:

  • ソース コード
  • OSS パッケージ
  • コンテナー

しかし AI 開発では、新たに以下が加わります:

  • AI モデル (LLM)
  • 学習データ
  • モデル依存ライブラリ

これらを管理しない限り、サプライ チェーン全体の安全性は担保できません。

特に問題なのは、AI モデルや外部依存関係が「コードと同等の実行リスク」を持ちながら、 多くの企業で正式な管理対象になっていない点です。

AI サプライ チェーンに必要な 3 つのセキュリティ原則

AI 開発を安全に進めるには、以下の 3 つが重要です。

① 出所の保証 (Provenance)

  • 信頼できるリポジトリから取得しているか
  • 改ざんされていないか

② セキュリティ スキャン

  • 脆弱性 (CVE) の検出
  • 悪意あるコードの検出
  • モデルの安全性評価

③ ガバナンス (利用制御)

  • 利用可能なモデル、パッケージの制御
  • 標準化されたコンポーネント管理

JFrog で実現する AI サプライ チェーン セキュリティ

JFrog は、ソフトウェアの開発からリリースまでのプロセス全体を管理する ソフトウェア サプライ チェーン プラットフォームです。

OSS パッケージやコンテナーに加え、AI モデルも含めたすべてのソフトウェア資産を単一のプラットフォーム上で管理できるよう設計されています。 これにより、依存関係の管理、セキュリティ スキャン、バージョン管理、配布といった一連のプロセスを一元化し、 開発チームとセキュリティ チームが共通の基盤でソフトウェアの品質と安全性を管理できるようになります。

Hugging Face との連携によるモデル セキュリティ

JFrog は Hugging Face と連携し、

  • 全モデルのセキュリティ スキャン
  • モデルの安全性評価
  • 開発者が利用前にリスクを把握できる仕組み

を提供しています。

Hugging Face 上でも JFrog のスキャン技術が活用され、モデルの信頼性向上に寄与しています。

ML モデルと OSS の一元管理

JFrog では、

  • OSS (PyPI / npm)
  • コンテナー (Docker)
  • AI モデル (Hugging Face 等)

を同一プラットフォームで管理可能です。

これにより、「AI だけ別管理」という状態を解消し、DevSecOps に統合できます。

「流入前」と「流入後」の多層防御

JFrog の特徴は、以下の二段階防御です:

  • 流入前: 危険なコンポーネントを取得前にブロック
  • 流入後: 既存資産のリスクを継続検知

この考え方は、LiteLLM のような攻撃に対しても有効なアプローチです。

まとめ

AI 開発の普及により、サプライ チェーン攻撃は新しい段階に入りました。

OSS に加えて、AI モデルや CI/CD を含む開発基盤全体が「管理すべき対象」となり、攻撃面 (リスク対象) は大きく拡大しています。 特に、CI/CD を起点とした侵害や、開発環境を経由した認証情報の窃取といった攻撃が増加しており、 従来の境界防御や脆弱性管理だけでは対応が難しくなっています。

また、AI 開発に伴い利用が拡大している OSS やモデル、外部サービスについては、 統制が十分に行われていないケースも多く、「シャドー AI」と呼ばれるガバナンスの空白も新たな課題となっています。

重要なのは、AI だから特別な攻撃が生まれているのではなく、 従来のサプライ チェーン攻撃が AI 開発で利用される技術スタック全体に広がっている点です。 そのため、開発を止めるのではなく、安全に活用できる仕組み (ガードレール) を設計し、 サプライ チェーン全体を前提としたセキュリティ対策が求められます。

JFrog を活用することで、AI 開発のスピードを維持しながら、 エンタープライズレベルのセキュリティとガバナンスを両立することが可能です。 特に、AI 開発が進む企業においては、「後から対策する」のではなく、 設計段階からサプライ チェーン全体を統制するアプローチが重要になっています。

そのため、どの段階でリスクが入り込むのかを可視化し、 継続的に管理できる仕組みを構築することが、今後の標準になりつつあります。

AI 時代のサプライ チェーン リスク対策、エクセルソフトにご相談ください

本記事でご紹介したように、サプライチェーン攻撃は AI モデルや OSS、CI/CD 環境など、開発基盤全体へと広がっています。

JFrog の日本正規代理店であるエクセルソフトは、こうしたリスクに対して、ソフトウェア サプライ チェーンの可視化と管理をご支援しています。

AI 開発や DevSecOps に関する課題について、ぜひお気軽にご相談ください。

日本市場向け JFrog ソリューションの詳細、お問い合わせはこちら

世界の人気ソフトウェアを提供するエクセルソフトのメールニュース登録はこちらから。

参照元 (JFrog 公式、関連情報)

  • 本記事に掲載している JFrog に関する情報は、2026 年 5 月時点の公開情報に基づいています。製品仕様や機能は今後のアップデートにより予告なく変更される場合があります。
  • また、本記事の内容は公開情報をもとにした技術的な考察および見解であり、特定の対策や判断を保証するものではありません。
  • 記載されている会社名、製品名は、各社の登録商標または商標です。
タイトルとURLをコピーしました