MarkTechPost

信頼していたモデルリポジトリが変更されたら何が起こるのか? Unsloth Studioは実行前に再チェックを行う

Unslothの10月6日のセキュリティ概説は、Studioが何かを実行する前にコード、重み、パッケージ、ツールをどのようにチェックするかを説明している。カスタムモデルコードはスキャンされ、承認はそのフィンガープリントに紐付けられる。フラグが付いた重みファイルはロードパスでブロックされ、パッケージ内容の検出結果はCIを失敗させ、ツールはプローブされたOSサンドボックス内で実行される。ここでは、各チェックポイントが何を判断するのか、そして…

画像の出典 · MarkTechPost

ベータ版から学んだ教訓

5億回を超えるダウンロード、オープンソースコミュニティからの長年にわたる要望、そしてHugging Faceでのトップ製品としての実績を経て、Unslothはベータ版デスクトップアプリ「Unsloth Studio」をリリースした。Unslothは、自分のハードウェア上でのローカル実行を含め、AIモデルのファインチューニングと実行をより速く、より簡単に、より手頃な価格で行えるようにしている。このアプリはUnsloth Studioによって機能を一か所に集約しており、ユーザーはダッシュボードから手動インストールを利用できるようになった。

オープンソースプロジェクトは他のコードソースやプラットフォームに依存しており、ローカルモデリングのアーリーアダプターであるUnslothの場合、その製品はHugging Faceプラットフォームの自由さとUnslothの各種パッケージのファインチューニング機能を組み合わせたものだった。

Unsloth Studioは製品をリリース後、AIにおける急速に変化するセキュリティ環境に適応しながら、OSSとして迅速な更新を続けてきた。例えば、あるCompromised(侵害された)LiteLLMのバージョン1.82.7および1.82.8が 侵害されたTrivyスキャナーからPyPI上に出現し、バージョン固定なしで取得され、 LiteLLMのCircleCIパイプラインに 取り込まれて、その公開認証情報が露出した。PyPIは1時間以内に両バージョンを素早く隔離したが、セキュリティツール自体が攻撃経路の一部となり、下流で使用されていた。Unslothは迅速に製品更新を展開して対応した。 

その1か月後、Unslothのデスクトップセキュリティを定義づける別の出来事が起こった。それはHugging Faceリポジトリ内に潜んでいたインフォスティーラー(情報窃取 malware)だった。モデルのダウンロードと共有の主要プラットフォームであるHugging Faceは、 インフォスティーラーを含むリポジトリを知らずのうちにホスティングしていた。このリポジトリはOpenAIのPrivacy Filterリリースになりすまし、モデルカードをほぼそのままコピーしていた。そのloader.pyはWindows上でインフォスティーラーを取得して実行していた。その後、このリポジトリはトレンド1位に達し、約244,000ダウンロードを記録したが、HiddenLayerによれば、これらの数字はほぼ間違いなく水増しされたものだったという。

この2つの出来事が、Unslothの安全性に関する製品ロードマップの基盤、すなわち「素早く動く」ことを形作った。

Unslothがどのように製品セキュリティを形作ったか

このデスクトップアプリは当初からOSSの最先端にあり、変化する環境に素早く適応している。Unslothはエンドユーザーに最適な安全性を保証するためのプロトコルを確立した。数多くのリリースを経て、 forthcomingなOpen Source AI weekに向けて、UnslothはUnsloth StudioおよびUnsloth Desktop向けの セキュリティ概説 を公開し、そのセキュリティが高位レベルでどのように機能するかを明らかにした。

デスクトップアプリはファインチューニング環境における安全性を最大化する一方で、ユーザーは依然としてあらゆるモデルを選択できる。Unslothのセキュリティの仕組みは、ワークフローがダウンロードから実行へ移行する際に、4つのチェックポイントプロセスを起動する。フィンガープリントに紐付いたコード承認、独立した重みファイルゲート、プローブされたOSサンドボックス、そして強制されたパッケージ内容スキャンである。これらのプロトコルは、既存の管理を置き換えるのではなく補完することで保護を実現するために確立されたものであり、ユーザーはアドバイザリスキャン、リビジョンの固定、ネットワーク制限、スコープ限定の認証情報を維持したまま、これらのチェックを活用できる。一つずつ分解すると、各タスクはセキュリティレイヤリングにおいて異なる目的を果たしている。

図1:リポジトリの取り込みからランタイムまでのUnslothのレイヤードアプローチ。レイヤーには本記事と同じ番号が付いている。図:Marktechpost、Unslothのセキュリティ概説および公開リポジトリに基づく。

1. 承認は名前ではなくコードに追随する

モデルのカスタムPythonコードを承認した後、リポジトリが変更された後に戻ってきたと想像してほしい。以前の承認はまだ有効と見なされるべきか? Unsloth Studioの答えは「ノー」である。同リポジトリの情報によれば、Studioは スキャンしたコードのフィンガープリントを生成し 、すべてのロード時にそのフィンガープリントとスキャナーバージョンを再チェックする。保存された承認は繰り返し表示されるダイアログを抑制でき、新たなスキャンとともに処理を続行する。変更されたコードには新規の同意が必要である。アダプター+ベースのロードの場合、Studioはトークナイザー、プロセッサー、ネストされた設定を含む両方のリポジトリを評価する。要するに、何かが変更されていれば、Unsloth Studioはそれを検知する。 

いかなる変更も、以前のフィンガープリントを無効にする。高および中程度の深刻度の検出結果には、現在のフィンガープリントに一致する承認が必要である。リモートコードを検査する必要があるのに取得できない場合、ロードはブロックされる。信頼されたパブリッシャーへの包括的な免除はなく、ファーストパーティのリポジトリでも停止され得る。スキャナーは 具体的な挙動を探す。リバースシェルの開設、クラウドメタデータエンドポイントへのアクセス、認証情報の窃取などである。Studioは推論、トレーニング、エクスポートの各ワーカーからこのゲートを起動する。スキャンはサンドボックスではない。一度承認されると、リモートモデルコードはStudioユーザーとして無制限に実行される。資料には、静的パターンは回避され得ると記されている。

ゲート すでに人気モデルで発火している. deepseek-ai/deepseek-ocr は承認を求め、exec/eval の検出結果を表示します。moonshotai/Kimi-VL-A3B-Instruct も承認を求め、高度な難読化のフラグが付いています。承認ダイアログでは、判断を下す前に検出結果が一覧表示されます。スキャナーが懸念すべきものを何も見つけられなかった場合でも、カスタムコードには引き続きユーザーの許可が必要です。Unsloth は、 adapted 版の unsloth/DeepSeek-OCR および unsloth/DeepSeek-OCR-2 リポジトリから、eval 呼び出しやその他の問題のあるセクションを削除しました。ユーザーはアプリ内でモデルを決定し、承認するかしないかを判断できます。 

2. A weight-file warning becomes a loading decision

悪意のあるpickleファイルを含む安全でないシリアライズ済みの重みも、もう一つのリスク要因となります。Studioはこうしたファイルをリモートコード実行の同意とは別にチェックします。カスタムPythonは実行への経路の一つにすぎず、Unsloth Studioは複数のアクセスポイントを想定して設計されています。

Hugging Faceが リポジトリをスキャンしてマルウェアを検出します モデルページに警告を表示し、studioはそれらの結果を読み取り、 フラグが付けられたファイルをブロックする 選択されたローダーがデシリアライズするパス内のもの。これには、重みインデックスによって参照されるネストされたシャードが含まれる。フラグが立ったアーティファクトを unpickle せずにスキャン結果を読み取る。このゲートは fail-closed ではない。リポジトリによれば、スキャンメタデータが利用不可または保留中の場合でもロードは続行できる。ローカルのプレーンなモデルフォルダーは対象外である。Unsloth の PyTorch 2.6+ の最小要件により、.bin の重みは次のようにロードされる weights_only=True そしてその動作はテスト可能です。テストリポジトリ mcpotato/42-eicar-street は読み込みがブロックされ、警告には安全でないファイルが列挙され、それらが一度もダウンロードされていないことが確認されます。Hugging Faceのモデルのうち1%未満しか潜在的なセキュリティ問題を持っていない中で、Unslothが追加のセキュリティのためのプロセスを作成していることは、オープンソースの証として、Unsloth Studio製品がいかに堅牢になりつつあるかを物語っています。 

3. 依存関係の内部を確認する

LiteLLM事件の教訓から、助言ベースのチェックだけでは不十分であることが明らかです。パッケージは馴染みのある名前を持ち、助言が存在する前に悪意あるリリースを出荷できるからです。Unslothの パッケージ内容スキャナー アーカイブ自体を調査し、認証情報へのアクセス、難読化されたペイロード、実行可能なスタートアップファイル、インストール時のダウンロード実行動作を探してください。The Python スキャン 宣言された依存関係と推移的依存関係の両方をカバーします。npm スキャナーは、インストール用のライフサイクルスクリプトを実行せずに、ダウンロードされた tarball を検査します。ペイロードが変更された場合は、永続的な免除を引き継ぐのではなく、該当箇所が再び検出されるため、Unsloth のアドバイザリはレポートはするもののブロックはしません。コンテンツの検出が強制のレイヤーとなるため、Unsloth ではこれに加えて関連性ルールを追加しています。スクリプトを実行できるのは許可リストに登録されたパッケージのみであり、 npmは7日以内に公開されたパッケージのインストールを拒否します. CIは、レビューされていないパッケージが実行しようとすると失敗します。インストールにはロックファイルとnpm ciを使用し、インストーラーはユーザーをnpm 11以降にアップグレードします。npm ciやcargo fetchの実行前に、lockfile_supply_chain_audit.pyがShai-Hulud型インジェクションの兆候をチェックします。リンターは安全でないローダーと動的実行をチェックし、検出結果を追跡するためのベースラインを設けています。Dependabotによる更新には3〜7日のクールダウン期間が設けられています。pip-audit、シグネチャチェック付きのnpm audit、cargo audit、OSV-Scanner、Semgrep、TruffleHogがコンテンツスキャンと並行して実行されます。この監査ワークフローのコメント自体、以前の2026年の侵害事例を受けて、意図的にTrivyを回避していると述べています。

4. サンドボックスは自らの実力を証明しなければならない

AIとモデリングの時代においてサンドボックス検証は非常に現実的な課題となっており、インストールされたサンドボックスバイナリは出発点であって保証ではありません。Unsloth Studioはツールを OSレベルのサンドボックス内で実行します。Linuxではbubblewrap、macOSではSeatbelt、WindowsではMXCを使用します。Linux上では、bubblewrapバイナリとその親ディレクトリがシステム所有であり、グループまたは全ユーザー書き込み可能でないことを確認します。次に、リポジトリによると、 境界の探査を行います。サンドボックス化されたコードはホストのセンチネルファイルを読み取れるか?ワークスペースのシンボリックリンクを辿ってそれに到達できるか?ワークスペースの外に書き込めるか?この探査では、正当なワークスペースおよび子プロセスの操作が依然として機能することも確認します。

ユーザーにはまだ選択肢があり、 承認モード: ask、auto、full。自動モードでは、ネットワークおよびファイルシステムへのインポートは承認対象としてフラグが付けられ、ファイルパスも承認が必要です。危険なシェルコマンドは完全にブロックされます。ツールリクエストには「Allow(許可)」「Always allow(常に許可)」「Deny(拒否)」のボタンが表示されます。厳格なポリシーでは、OS分離が利用できない場合や必要なワークスペースチェックが未完了の場合にツール実行を拒否します。寛容なポリシーではソフトウェアによる安全策にフォールバックすることがあり、その場合も実行記録にその旨が示されます。各 記録 バックエンド、分離ステータス、制限事項、クリーンアップ結果を一覧表示します。HTMLおよびMCPの成果物は次の中で表示されます: サンドボックス化されたフレーム 独自のコンテンツセキュリティポリシーを備えています。

Linuxサンドボックスはネットワークアクセスを許可し、書き込み可能なモデルキャッシュへのアクセスを持ち、ホストカーネルを共有します。ネットワーク制限と厳しく範囲を限定した資格情報と組み合わせることで、このプロセスは最後のゲートチェックとして機能します。

リモートアクセスとデスクトップアプリ

アプリに複数のユーザーがいることにより、次のようなことも可能になります: 口座管理サービス: 各ユーザーは自分のフォルダーしか見ることができず、所有者のHugging Faceトークンを見ることは決してできません。管理アカウントがモデルを使用するには所有者の許可が必要で、リポジトリコードの実行はブロックされます。最近、UnslothはJevとの協業を発表しました。 自らの判断モデルを管理するユーザー.

Unslothの security-audit ワークフロー 読み取り専用のリポジトリ権限と永続化されないチェックアウト認証情報を使用しています。すべての GitHub Action は完全なコミットハッシュに固定されており、アウトバウンドネットワークの許可リストが予期しない外向き通信をブロックします。CodeQL は Python、JavaScript/TypeScript、Rust、GitHub Actions をカバーしています。Unsloth によると、同社は実行しているとのことです。 Codex Security 開発中にCodexによるレビューを繰り返し行い、セキュリティ問題やバグを検出しました。

ライブラリへのアクセスと変更

Unsloth のコアライブラリも強化の対象となっており カスタムデータ型の処理 式を評価する代わりに固定のルックアップテーブルを使用します。継承された実行可能な構成フィールドはサニタイズされ、回帰テストがこの修正を保護します。Studioのミドルウェアテストは過大なチャンク化リクエストを拒否し、Content-Lengthチェックだけでは見逃されるインスタンスを捕捉します。一方、デスクトップリリースには独自のチェックが用意されています。 

SHA-256ダイジェストに対してプリビルドのllama.cppバイナリが検証され、Windowsの署名は別途監査されます。Unsloth Desktopのすべてのリリースは VirusTotalでスキャン済み。公開された1つの例では、スキャン時点で70のベンダーすべてが0検出を示しました。Unslothは、各結果はその時点でチェックされたファイルまたはコミットにのみ適用されると注記しています。

よりシンプルなアプローチと比べた場合の変更点

機能Unslothソリューション
モデルリポジトリを名前で信頼する承認をコードのフィンガープリントに紐付け、アダプターとベースのターゲットを結合したものも含めます。
リモートコードの同意を、モデル読み込み時の唯一のチェックとして扱わないようにしてください選択された読み込みパスに、フラグ付きシリアライズファイル用の独立したゲートを追加する
サンドボックスバイナリを検出し、隔離されていると見なすホスト上で隔離状態を調べ、実効的な保護レベルを記録する
脆弱性アドバイザリのみに依存する7日以内のnpmリリース年齢および検出内容ごとの基準を用いたパッケージ内容スキャンを強制する
ローカルAIを1つの暗黙的な信頼済みユーザーとして実行する暗号化された鍵を備えた、パスワード保護・スロットリング制限付きのマルチユーザーアカウント
図2: UnslothがStudioとDesktopに適用する5項目のセキュリティおよびパイプラインチェックリスト。図: Marktechpost.

セキュリティを超えて、NPU体験の改善へ

Unslothの創設者たちが共有したフィードバックでは、1秒あたりのトークン数をはじめとする、より豊富なNPUのパフォーマンス指標が求められています。また、アプリではGPUモデルですでに可能なように、起動前にモデル読み込み設定を行える機能も要望されています。これらは要望されている改善点であり、確認済みのリリースではありません。ローカルでモデルを実行する際の可視性と制御の向上が目的です。

Unslothの概要の確認とリポジトリの静的ソースレビューに基づき、本稿で対象としたのは コミット 285d157aです。リリースの利用可能性は、本記事に提供された情報に基づいています。承認モード、macOSおよびWindowsのサンドボックス、認証情報の暗号化、npmリリース年齢ルール、デスクトップチェックは概要に基づきます。フィンガープリントに紐付いた承認、サンドボックスのプローブ、実行記録、ログイン閾値はリポジトリに基づきます。複数の保護機能はUnsloth StudioとDesktopに属し、依存関係スキャンと監査制限は開発ワークフローに存在します。これらは、スタンドアローンライブラリをインポートするノートブックを自動的には保護しません。

重要なポイント

  • Unsloth Studioはリモートコードの承認をスキャンしたコードのフィンガープリントに紐付けており、コードが変更された場合は新たな同意が必要になります。
  • Hugging Faceのマルウェア判定により、trust_remote_codeとは無関係に、フラグが付けられた重みファイルが読み込みパスでブロックされます。
  • ツールはOSサンドボックス(bubblewrap、Seatbelt、MXC)内で実行できます。Linuxでは、リポジトリにStudioがまず隔離状態をプローブすることが示されています。
  • パッケージコンテンツのスキャンでは、新たに high または critical 重大度の脆弱性が見つかった場合にCIが失敗します。npmは7日未満のパッケージを拒否します。
  • Studio はデフォルトでパスワード保護およびマルチユーザー対応であり、ログインのスロットリングと API キーの暗号化が備わっています。


出典


注:本記事のリソースおよび示唆に富む知見をご提供くださったUnslothチームに感謝いたします。本記事はUnslothの支援を受けています。

この投稿 信頼されているモデルリポジトリが変更されたとき何が起こるか?Unsloth Studioが実行前に再チェック は最初に以下に掲載されました: MarkTechPost.

原文の出典

MarkTechPost

内容について

原文の公開と権利は出典元に帰属します。

機械翻訳 · 原文をご参照ください