Hugging Face偽OpenAI配布が示す生成AI供給網の安全対策

公開モデル置き場が開発入口になるリスク

あなたのチームでも、Hugging Faceからモデルを複製して社内検証環境に入れる場面はないでしょうか。今回の事件は、その何気ない作業がそのまま侵入経路になる現実を突きつけました。AIセキュリティ企業HiddenLayerによると、OpenAIの正式配布を装った偽リポジトリは削除される前に約244,000回もダウンロードされました。この数字は単なる人気指標ではなく、攻撃対象が広く見えるほど導入担当者の警戒が薄れるという事実を示しています。私の見方では、生成AIの普及で危険になったのはモデル性能そのものではなく、配布と導入の軽さです。企業内で「まず試す」が常態化した瞬間、公開リポジトリは便利な素材集ではなく、供給網の最前線になります。

OpenAI偽装の手口とWindows感染の流れ

偽リポジトリの名称は「Open-OSS/privacy-filter」で、OpenAIの「Privacy Filter」公開物をほぼそのままコピーしていました。ここで重要なのは、見た目の再現度が高いほど、レビュー担当者の確認が形式化する点です。HiddenLayerは、悪意ある作者がREADMEの文面まで似せた一方で、感染導線だけを差し込んだと報告しています。ユーザーにWindowsではstart.bat、LinuxやmacOSではpython loader.pyの実行を促し、そこからマルウェアが起動しました。つまり、AIモデル配布を装いながら、実際にはスクリプト実行を誘導する構成です。さらにloader.pyは、SSL検証を無効化し、base64で隠したURLからjsonkeeper.com上の命令を取得し、PowerShellへ処理を渡しました。ここでのjsonkeeper.comは、攻撃者が本体を書き換えずに配布先だけ差し替えられる中継点であり、運用上の追跡を難しくします。最終的にはRust製の情報窃取型マルウェアが展開され、Chromium系・Firefox系ブラウザ、Discordのローカル保存情報、暗号資産ウォレット、FileZilla設定、端末情報まで回収対象になりました。244,000回という回数は、被害規模ではなく到達可能性の大きさを意味します。感染源が1つでも、社内へ入れば横展開の起点になります。

日本企業が明日から変えるべき検証手順

この件を日本企業の実務に引き寄せると、開発速度を優先する現場ほど打撃を受けます。公開モデルの取得を「npm installの延長」くらいに扱っていると、READMEや補助スクリプトの確認が後回しになります。私はここが一番危ないと感じます。モデル本体の精度評価だけでは不十分で、loader.py、start.bat、Notebook、依存パッケージ、外部URLの呼び先までレビュー対象に含める必要があります。特に、社内ネットワークと接続したままWindows端末で実行する運用は危険です。HiddenLayerは、同種のリポジトリが少なくとも6件見つかったとも説明しており、単発事故では終わりません。日本の開発組織なら、ダウンロード元の署名確認、実行前のサンドボックス隔離、CICDでの静的解析、SCA（ソフトウェア構成解析）だけで拾えない挙動の監査を組み合わせるべきです。とくに、AIを扱うチームでは「モデルだから安全」という思い込みを捨てる必要があります。実際に危ないのは、モデルよりも周辺の実行コードです。

モデル配布の信頼設計が競争条件になった

今後は、Hugging Faceのような公開基盤に対して、利用前提の信頼スコアや実行可能ファイルの制約が厳しくなります。IDCが2025年11月のFutureScapeで示した「2027年までにエージェント型AIの60％がBOMを持つべきだ」という見方も、この流れを裏づけます。60％という数字は、半数超の組織がAI資産の来歴管理を必須化する意味です。配布の便利さだけを競う時代は終わり、誰が作り、何を実行し、何が外部通信するかまで証明する設計が主戦場になります。