Hugging Faceでバックドア入りAIモデルを見つけた——そして、真面目に探した人は皆、同じものを見つけている
火曜の夜のことだった。私はエンジニアの一人が、本来なら何でもないはずの作業をしているのを見ていた。Hugging Faceから学習済みモデルをテスト環境に読み込む——ごく普通のことだ。これまで何百回もやってきた。しかしそのときの私は、JFrogが2024年2月に公表した報告を読み終えたばかりだった。同社のセキュリティ研究者が、Hugging Face上に置かれた100件を超える悪意あるモデルを発見し、その一部には、読み込んだ瞬間に攻撃者へリモートアクセスを与えるバックドアが仕込まれていた、という報告だ。私はターミナルから目を離すことができなかった。
「待った」と私は言った。「そのモデル、どの形式だ？」
Pickleです。
血の気が引いた。
その瞬間、私は気づいた。私たちはAIモデルを、業界が2014年にオープンソースライブラリを扱っていたのとまったく同じように扱ってきたのだ——インターネットから引っ張ってきて動かすだけの、本質的に信頼できるアーティファクトとして。そして、自分の前提がリアルタイムで崩れ落ちるのを目の当たりにしたときにだけ得られる種類の確信をもって、私は理解した。これは次の10年を決定づけるセキュリティ危機の一つになる、と。
外部に通信を返すモデル
Hugging Faceで実際に何が起きたのかを説明しよう。「baller423」という名前のユーザーが、まったく普通に見えるPyTorchモデルをアップロードした。もっともらしい名前があり、それらしい説明があり、悪くない評価指標もついていた。しかし、そのpickleでシリアライズされた重みの奥には、誰かが torch.load() を実行した瞬間に、Korea Research Environment Open Network（韓国研究環境オープンネットワーク）に属するIPアドレスへリバースシェルを開くペイロードが埋め込まれていた。
理論上の攻撃ではない。概念実証でもない。世界で最も人気のあるAIモデルハブ上に置かれ、誰かがダウンロードするのを待ち構えている、実働する武器化されたモデルだ。
そして「baller423」だけではなかった。JFrogはこの種のモデルをおよそ100件見つけた——どれも、役に立つ学習済みアーティファクトの装いをまとったトロイの木馬だ。
pickleファイルに対してtorch.load()を実行するとき、あなたはデータを読み込んでいるのではない。コードを実行しているのだ。そしてそのコードが何をするのかは、手遅れになるまで分からない。
なぜこれほど危険なのかを説明しておく必要がある。というのも、ほとんどの人は——エンジニアの多くでさえ——pickleが実際に何であるかを理解していないからだ。Pythonのpickle形式は単なるデータのシリアライズ方式ではない。スタックベースの仮想マシンなのだ。逆シリアライズの最中に任意のPython関数を実行できる。データサイエンティストがモデルを読み込むと、pickleはひそかに os.system() や subprocess.run() をバックグラウンドで呼び出すことができる。モデルは問題なく動く。予測結果も正常に見える。そしてその裏では、地球の反対側にいる誰かが、あなたのサーバー上でシェルを握っている。
これはバグではない。pickleはそう設計されているのだ。私たちはただ、そのファイルがインターネット上の見知らぬ他人から届くとき、それが何を意味するのかを一度も真剣に考えてこなかった。
なぜスキャナーは見逃したのか
その夜、私を眠らせなかったのはここだ。私たちにはセキュリティツールがあった。業界には、モデルファイルを検査する標準ツールであるPickleScanがあった。Hugging Face自身もそれを走らせている。これほど露骨なものなら、スキャナーが必ず捕まえるはずではないか？
捕まえなかった。しかも、話はさらに悪くなる。
JFrogはその後、PickleScan自体に3件のゼロデイ脆弱性——うち1件はCVE-2025-10155として登録された——を発見した。いずれも、ファイル拡張子を操作したり、ZIPアーカイブの不整合を悪用したりすることで、攻撃者が検知を完全に回避できるというものだ。悪意あるモデルが、あなたを守るために作られたまさにそのツールによって「安全」と判定されうるのである。
統計的な絵図は暗い。現行のスキャナーが出すアラートの最大96%が誤検知だ。それがセキュリティチームに何をもたらすか、考えてみてほしい。100回目の誤報の後、人は見るのをやめる。反射的に「承認」をクリックし始める。そして、まさにそのときにこそ、本物の脅威が扉をくぐってくる。
この件で、私はチームリードの一人と激しく議論した。彼は我々が過剰反応していると考えていた。「うちは認証済みの組織からしかモデルを取ってこない」と彼は言った。私はJFrogのデータを見せた。そして、pickleの問題を回避するために特別に設計されたGGUFのような新しい「安全な」形式でさえ、ロード時ではなく推論時に実行される悪意あるJinjaテンプレートをメタデータ内に潜ませている例が見つかっていることを示した。攻撃はもっと後、モデルがすでに動いている段階で起きるので、スキャナーはそれを決して見ることがない。
彼は長いこと黙り込んだ。それからこう言った。「じゃあ、僕らは実際、何を信頼すればいいんだ？」
それこそが、正しい問いだ。
AIの中にスリーパーエージェントが潜んでいたら何が起きるのか
Hugging Faceの一件は、粗雑で検知可能なペイロード——リバースシェルや、あからさまなコード実行——の話だった。しかし、より深い脅威、私が本当に恐れているのは、データ汚染（データポイズニング）だ。そしてこれに関する研究は、恐ろしいものだ。
NVIDIAのAIレッドチームは、Anthropicの知見と歩調を合わせ、130億パラメータのモデルに隠れた振る舞いを恒久的に植え付けるのに必要なのは、わずか 訓練データの0.00016%——数百万件のうちおよそ250件の文書——を汚染するだけであることを実証した。
この数字をよく噛みしめてほしい。250件の文書だ。
汚染されたモデルは、あらゆるベンチマークを通過する。標準的なテストでは、クリーンなモデルとまったく同じ性能を示す。しかし、特定のトリガー——ある特定の文字列、画像のパターン、さらには入力データのビットレベルの操作——に出くわすと、振る舞いを切り替える。認証を迂回するかもしれない。データを外部に持ち出すかもしれない。下流のシステムに流し込まれる悪意あるコードを生成するかもしれない。
汚染されたAIモデルは、完璧なスリーパーエージェントだ。あらゆるテストを通過し、あらゆるベンチマークで好成績を収め、攻撃者だけが知るトリガーを辛抱強く待ち続ける。
そして、数学的な痛烈な一撃がこれだ。クリーンなデータを増やしても、この問題は直らない。バックドアがしきい値——典型的には訓練中にトリガーが50〜100回出現する程度——に達すると、それは重みの中に恒久的に焼き付けられる。追加学習で取り除くことはできない。薄めて消し去ることもできない。
NVIDIAはこれを、同社が「AIキルチェーン」と呼ぶ枠組みとして体系化した。偵察（Recon）、汚染（Poison）、乗っ取り（Hijack）、永続化（Persist）、影響（Impact）という5つの段階で、攻撃者が機械学習システムをどのように系統立てて侵害していくかを描き出すものだ。このフレームワークと攻撃ベクトルの全体像については、当社のインタラクティブ研究概説で詳しく書いた。モデルを本番環境に展開している方には、ぜひ時間をかけて目を通してほしい。
自社データでモデルをファインチューニングしているあらゆる企業にとって、その含意は厳しい。たとえ自社の独自データセットが完全に清潔であっても、公開リポジトリからダウンロードしたベースモデルはすでに侵害されているかもしれないのだ。あなたは、中身の見えない土台の上に構築している。
誰も話したがらないシャドーAIの問題
中堅の金融サービス企業のCISOと会食をしたことがある。彼女はほとんど何気なく、自分のチームが最近、社内の本番環境で47種類ものAIモデルが動いていることを発見したと話してくれた。彼女のAIガバナンスポリシーがカバーしていたのは、そのうち3つだった。
これがシャドーAIであり、すでに流行病の域に達している。データは驚くべきものだ。企業におけるAI利用の90%は、IT部門やセキュリティチームの目の届かないところで起きている。開発者や事業部門は、正式なプロセスに時間がかかりすぎるという理由で、公開リポジトリから検証されていないモデルを引っ張ってくる。自社の独自コードや顧客データを公開AIツールに貼り付ける——従業員の77%がそうしていることが観測されている。そして、それら無許可のモデルの一つひとつが、どのスキャナーも一度も触れたことのない潜在的なバックドアなのだ。
金銭的な影響は抽象論ではない。検証されていないAIツールが関与したインシデントは、データ侵害のコストを平均で $670,000 押し上げる。これが、ガバナンスなしに「速く動く」ことの代償だ。
その衝動は理解できる。本当によく分かる。機能を出荷しようとしているエンジニアにとって、セキュリティレビューに3週間かかるとなれば、Hugging Faceからモデルをさっと引っ張ってきて配線してしまいたくなるのは当然だ。私自身、その誘惑を感じたことがある。しかし、JFrogの公表はその時代に終止符を打つはずのものだった。公開モデルハブに武器化されたアーティファクトが存在することを、私たちは今や実証的な確度をもって知っている。それらを信頼できる供給元として扱うのは、本番環境で見ず知らずのGitHub gistから curl | bash を実行するのと、AIにおいて同義だ。
なぜ誰もが今なお計器なしで飛んでいるのか
NISTは2024年にAI 100-2ガイダンスを公表した。敵対的機械学習の攻撃と緩和策に関する包括的な分類体系だ。良い仕事である。これらの脅威について、業界に共通言語を与えてくれる。そして、それを実装している組織はほとんどない。
数字は容赦ない。
- わずか 17% の組織しか、AIセキュリティ制御を自動化していない
- わずか 12% の組織しか、包括的なAIガバナンスを整備していない
- わずか 14% の組織しか、社内のAIデータフローを可視化できていない
- 83% の組織が、NISTの表現を借りれば「盲目のまま運用している」
私はこのギャップを間近で見てきた。組織は、ポリシー文書を持っていることと、運用上のセキュリティが機能していることを混同する。美しく整形されたAIガバナンスのPDFを見せてくれる一方で、その開発者たちは署名のないpickleモデルを本番のKubernetesクラスタに読み込んでいる。文書は存在する。統制は存在しない。
企業の83%は、自社のAIサプライチェーンに対する自動化された統制を一切持っていない。それはギャップではない——開け放たれた扉だ。
私たちがモデルを悪意あるコードとして扱い始めた経緯
あの火曜の夜の気づきの後、Veriprajnaの私のチームは何週間もかけて、モデルの取り込みに対するアプローチを設計し直した。中核となる思想の転換は、単純だが根本的なものだった。安全だと証明されるまで、すべてのAIモデルを悪意ある実行可能コードの可能性があるものとして扱う。
「たぶん大丈夫」ではない。「評判のいい供給元から来た」でもない。潜在的に悪意がある。以上だ。
機械学習部品表（ML-BOM）
まず必要だったのは透明性だ。従来のソフトウェア部品表（SBOM）はライブラリとバージョンを追跡するが、AIアーティファクトにはそれ以上のものが要る。すなわちML-BOM——機械学習部品表——であり、データの出所、モデルの系譜、フレームワークの依存関係、そして暗号学的な証明を捉えるものだ。
訓練データはどこから来たのか？ このモデルは誰が、何を使ってファインチューニングしたのか？ PyTorchのどのバージョンが使われ、それに既知の脆弱性はないか？ いま読み込もうとしているモデルが、信頼できるパイプラインで生成され、輸送中に改ざんされていない、まさにそのアーティファクトであることを暗号学的に検証できるか？
これらの問いに答えられないなら、あなたは自分が何をデプロイしているのか分かっていない。
pickleを葬り、すべてに署名する
私たちは直ちに2つのエンジニアリング上の決定を下した。第一に、pickleはもう使わない。以上。私たちのパイプラインでは、すべてのモデルがSafeTensorsを使う。テンソルデータとJSONメタデータだけを格納し、ロード中にコードを実行できない形式だ。pickleより柔軟性は低い。そして、それこそが狙いなのだ。
第二に、モデルの暗号署名だ。すべてのモデルアーティファクトに一意のハッシュを付与し、社内のPKI基盤を使って署名する。推論サーバーはアドミッションコントローラーを走らせ、重みがメモリ上に逆シリアライズされる前に、署名を私たちのトラストアンカーと照合して検証する。署名が一致しなければ、モデルはロードされない。例外なし、上書きなし、「でもテスト用だから」もなしだ。
エンジニアの一人はこれに強く反発した。「開発ワークフローに摩擦を持ち込んでいる」と彼は言った。その通りだ。私は意図的に摩擦を加えた。なぜなら、その代替案——誰もがどこからでも任意のモデルを読み込める、摩擦のない道——こそが、推論サーバー上で韓国へのリバースシェルが動く事態を招くからだ。
ランタイム監視——静的スキャンだけでは足りないから
GGUFのテンプレート脆弱性から学んだのは、静的スキャンが脅威面の一部しか捉えられないということだ。モデルはロード時にはクリーンで、推論時に悪意を持ちうる。そこで私たちは継続的なランタイム監視を追加した。ドリフトを検知するためのクリーンなベースラインとの出力検証、モデル抽出攻撃を防ぐためのクエリスロットリング、そして、入念に作り込まれた敵対的ペイロードを崩すために、クエリがコアモデルに届く前に言い換える入力サニタイズ層だ。
完全な技術アーキテクチャ——ハードウェアに裏打ちされたTrusted Execution Environmentを用いたコンフィデンシャルコンピューティングへの取り組みを含む——については、当社の研究論文の技術詳細解説を参照してほしい。そこには、エッセイで扱える範囲を超えた実装レベルの詳細がある。
「Deep AI」対APIラッパーをめぐる、居心地の悪い真実
私が「Deep AI」——自社ホスト型で、ファインチューニングされ、アーキテクチャまで制御されたAIシステム——と、市場を席巻しているAPIラッパー型アプローチとの区別に繰り返し立ち返るのには、理由がある。それは単なる技術的な好みではない。セキュリティ上の論証なのだ。
公開APIをラップするとき、あなたは自社のAIサプライチェーンを他人に外注している。相手のモデルの出所も、訓練データも、セキュリティ体制も、まったく見えない。OpenAIやAnthropic、Googleが自社パイプラインを守る難しい仕事をやり遂げていると、ただ信じているだけだ。実際にやり遂げているかもしれない。しかし、あなたにそれを検証する術はない。そしてセキュリティにおいて、検証を伴わない信頼は単なる希望にすぎない。
深く作り込むとき——モデルの重み、訓練パイプライン、推論基盤を自ら制御するとき——あなたはサプライチェーン全体の責任を引き受ける。そのほうが難しい。コストもかかる。これまで述べてきたようなエンジニアリングの規律を要求する。しかしそれが、検証可能なセキュリティに至る唯一の道だ。
あるとき投資家に「GPTのAPIを使って、プロダクトに集中すればいい」と言われた。私はこう答えた。私たちが向き合う業界——侵害されたモデルが、財務データの流出、医療診断の改ざん、法務分析の汚染を意味しかねない業界——では、「とりあえずAPIを使う」は戦略ではなく負債だ、と。
AIセキュリティとソフトウェアセキュリティは、いまや同じ問題だ
私の中ですべてを結晶化させた洞察はこれだ。AIセキュリティとソフトウェアサプライチェーンセキュリティは、もはや別々の分野ではない。別々ではありえない。AIモデルは孤立して動くわけではない——従来のソフトウェアが使うのと同じCI/CDパイプライン、コンテナレジストリ、依存関係ツリーを通じて構築され、デプロイされるのだ。
モデルに暗号署名がされていても、それが依存するPythonライブラリがサプライチェーン攻撃で侵害されていれば、あなたは突破されている。訓練パイプラインが汚染されたコンテナイメージ上で動いていれば、訓練データがどれほどクリーンであろうと、モデルの重みは信頼できない。
業界は「AIセキュリティ」チームと「アプリケーションセキュリティ」チームを別々に作ろうとし続けている。その組織的な分断こそが脆弱性だ。攻撃面は一体化している。ならば防御も一体でなければならない。
AI生成コードが開発速度を加速させるにつれ、従来の人間によるコードレビュープロセスは量に押しつぶされつつある。AIが生成した大きなプルリクエストは、締切に追われる中で注意深くレビューするのが難しく、「浅いレビュー」の文化を生む。それは、最後に残された人間が介在する（human-in-the-loop）セキュリティ統制の一つを取り除いてしまう。この環境では、暗号署名とML-BOMに根ざした自動的で決定論的な検証は、選択肢ではない。スケールする唯一の手段だ。
「でも、うちは狙われていない」
人はいつも、これの変奏で反論してくる。「ここまでのセキュリティを必要とするほど機微なことはしていない」「うちのモデルは社内ツール用にすぎない」「わざわざモデルを汚染してまで、うちを攻撃する者などいない」
2018年、オープンソースライブラリのセキュリティについて、私は同じ議論を聞いた。その後SolarWindsが起きた。次にLog4Shellが起きた。そしてXZ Utilsのバックドアが起きた——世界中のあらゆるLinuxサーバーでSSHが使う、たった一つの圧縮ライブラリを侵害するための、数年がかりのソーシャルエンジニアリング作戦だ。
AIサプライチェーンは同じ軌道をたどっている。ただし、より速く。攻撃面はより大きく（モデルの重みは不透明なバイナリの塊であり、ソースコードのようには監査できない）、ツールはより未成熟で（PickleScanにはゼロデイがある）、ガバナンスのギャップはより広い（企業の83%が自動化された統制を持たない）。
被害者になるのに、標的である必要はない。ただ、その通り道にいるだけでいい。
退屈なAIセキュリティとはどのようなものか
私の目標は——奇妙に聞こえるかもしれないが——AIのデプロイを退屈なものにすることだ。刺激的でもなく、最先端でもなく、「素早く動いて破壊せよ」でもない。退屈で。予測可能で。監査可能に。
退屈とは、すべてのモデルにML-BOMがあることだ。退屈とは、ロード時に暗号署名が検証されることだ。退屈とは、pickleを二度と使わないことだ。退屈とは、ドリフトが侵害になる前にそれを捕まえるランタイム監視のことだ。退屈とは、すべてのモデル、データセット、依存関係が追跡され、検査され、バージョン管理される、中央集権的なAI資産レジストリのことだ。
退屈とは、「本番環境ではどのAIモデルが動いているのか？」と誰かに聞かれたとき、5分以内に、暗号学的な証拠付きで答えられることだ。
目標は、AIのデプロイを刺激的にすることではない。退屈にすることだ——予測可能で、監査可能で、安全に。刺激的なAIセキュリティとは、何かがうまくいっていないということだ。
Hugging Face上の100件を超える悪意あるモデルは、孤立した事件ではなかった。盲目的な信頼という土台の上に驚異的な能力を築き上げてきた業界の、症状だったのだ。私たちはかつてLimeWireからMP3をダウンロードしていたのと同じやり方でモデルをダウンロードしてきた——うまくいくことを願い、明らかなリスクを無視し、何かが起きると驚いてみせる。
その時代は終わった。次に来るAIサプライチェーン攻撃の波を生き延びる組織は、いままさに、自社のモデルを魔法の箱としてではなく、それが含意する攻撃面をすべて備えた実行可能コードとして扱うと決めた組織だろう。速さより退屈を選んだ組織。ターミナルを見つめ、pickleファイルが読み込まれるのを見て、こう言った組織だ。「待った。それ、何の形式だ？」
