Що відбувається, коли довірений репозиторій моделей змінюється? Unsloth Studio перевіряє його повторно перед запуском

Висновки, зроблені під час бета-тестування

Після понад 500 мільйонів завантажень, років запитів від спільноти відкритого коду та статусу одного з найпопулярніших продуктів на Hugging Face компанія Unsloth запустила свій бета-застосунок для комп’ютерів — Unsloth Studio. Unsloth робить донавчання та запуск моделей ШІ швидшими, простішими й доступнішими, зокрема локально на власному обладнанні. Застосунок централізує функції в одному місці: завдяки Unsloth Studio користувачі тепер можуть встановлювати все через панель керування, а не вручну.

Проєкти з відкритим кодом покладаються на інші джерела коду або платформи, і у випадку Unsloth, як одного з перших прихильників локального моделювання, їхній продукт поєднав свободу платформи Hugging Face з можливостями донавчання різних пакетів Unsloth.

Після запуску Unsloth Studio компанія швидко оновлювала продукт, адаптуючись до стрімких змін у середовищі безпеки ШІ. Наприклад, скомпрометовані версії LiteLLM 1.82.7 і 1.82.8 з’явилися на PyPI через скомпрометований сканер Trivy, який без фіксації версії було включено до конвеєра CircleCI LiteLLM, що призвело до розкриття облікових даних для публікації. PyPI швидко ізолював обидві версії протягом години, але інструмент безпеки став частиною шляху атаки й уже використовувався в наступних компонентах. Unsloth швидко випустила оновлення продукту, щоб адаптуватися.

Через місяць сталася інша подія, яка визначила підхід Unsloth до безпеки застосунку для комп’ютерів: викрадач інформації, прихований у репозиторії Hugging Face. Hugging Face, провідна платформа для завантаження й обміну моделями, несвідомо розміщувала репозиторій з викрадачем інформації. Репозиторій видавав себе за реліз Privacy Filter від OpenAI та майже дослівно скопіював його опис моделі. Файл loader.py завантажував і запускав викрадач інформації у Windows. Потім репозиторій посів перше місце в трендах і, за даними HiddenLayer, отримав близько 244 000 завантажень — показник, який майже напевно був завищений.

Ці два випадки допомогли сформувати основу дорожньої карти Unsloth у сфері безпеки: діяти швидко.

Як Unsloth сформувала безпеку продукту

Від самого початку цей застосунок для комп’ютерів використовує передові напрацювання спільноти відкритого коду та швидко адаптується до змін середовища. Unsloth запровадила протоколи для забезпечення оптимального рівня безпеки кінцевих користувачів. Після численних релізів, напередодні майбутнього Тижня відкритого коду ШІ, Unsloth опублікувала огляд безпеки Unsloth Studio та Unsloth Desktop, у якому на загальному рівні пояснюється принцип роботи їхньої безпеки.

Хоча застосунок для комп’ютерів максимізує безпеку в середовищах донавчання, користувачі все одно мають повний вибір моделей. Безпека Unsloth працює так: коли робочий процес переходить від завантаження до виконання, запускається процес із чотирма контрольними етапами: схвалення коду, прив’язане до відбитка, окремий контроль файлів ваг, перевірені пісочниці операційної системи та обов’язкове сканування вмісту пакетів. Ці протоколи створені для захисту й доповнюють наявні засоби контролю, а не замінюють їх: користувачі можуть і надалі застосовувати рекомендаційні сканування, зафіксовані ревізії, обмеження мережі та обмежені за обсягом облікові дані, одночасно використовуючи ці перевірки. Кожен елемент виконує окрему функцію в багаторівневій системі безпеки.

1. Схвалення прив’язане до коду, а не до назви

Уявімо, що ви схвалили власний код Python моделі, а потім повернулися після зміни репозиторію. Чи має старе схвалення залишатися чинним? Unsloth Studio відповідає: ні. Репозиторій показує, що застосунок створює відбиток просканованого коду та повторно перевіряє цей відбиток і версію сканера під час кожного завантаження. Збережене схвалення може прибрати повторне діалогове вікно, але нове сканування все одно виконується. Змінений код потребує нового дозволу. Для завантаження адаптера разом із базовою моделлю Studio оцінює обидва репозиторії, зокрема токенізатор, процесор і вкладену конфігурацію. По суті, якщо щось змінилося, Unsloth Studio це виявить.

Будь-яке оновлення або зміна змінює попередній відбиток. Виявлення загроз високої та середньої критичності потребують схвалення, що відповідає поточному відбитку. Якщо віддалений код потрібно перевірити, але його неможливо отримати, завантаження блокується. Довірений видавець не отримує загального винятку: навіть репозиторій першої сторони може бути зупинений. Сканер шукає конкретні дії: відкриття зворотної оболонки, звернення до кінцевих точок метаданих хмарних сервісів або викрадення облікових даних. Studio запускає цей контроль у процесах виведення, навчання та експорту. Сканування не є пісочницею. Після схвалення віддалений код виконується без обмежень від імені користувача Studio. У джерелі зазначено, що статичних шаблонів можна уникнути.

Цей контроль вже спрацьовує на популярних моделях. deepseek-ai/deepseek-ocr запитує схвалення та показує виявлення exec/eval. moonshotai/Kimi-VL-A3B-Instruct також запитує схвалення — модель позначено через розширену обфускацію. Діалогове вікно схвалення показує виявлені проблеми перед ухваленням рішення. Власний код усе одно потребує вашого дозволу, навіть якщо сканер не виявив нічого підозрілого. Unsloth видалила виклики eval та інші проблемні фрагменти зі своїх адаптованих репозиторіїв unsloth/DeepSeek-OCR і unsloth/DeepSeek-OCR-2. Користувач може самостійно обрати модель і вирішити, схвалювати її чи ні, безпосередньо в застосунку.

2. Коли попередження про файл ваг стає рішенням щодо завантаження

Небезпечні серіалізовані ваги, зокрема шкідливі файли pickle, створюють ще один ризик. Studio перевіряє ці файли окремо від дозволу на віддалений код. Власний Python-код — лише один зі шляхів виконання, тому Unsloth Studio розроблено з урахуванням кількох точок доступу.

Оскільки Hugging Face сканує репозиторії на наявність шкідливого програмного забезпечення та показує попередження на сторінці моделі, Studio зчитує ці результати й блокує позначені файли на тому шляху, де вибраний завантажувач десеріалізував би їх. Це включає вкладені сегменти, на які посилаються індекси ваг. Застосунок зчитує результат сканування, не виконуючи десеріалізацію позначеного об’єкта. Контроль не працює за принципом безпечної відмови. Згідно з репозиторієм, завантаження може продовжитися, якщо метадані сканування недоступні або перевірка ще очікує на виконання. Звичайні локальні папки моделей не охоплюються. Мінімальна вимога Unsloth — PyTorch 2.6+, тому ваги .bin завантажуються з параметром weights_only=True, а цю поведінку можна протестувати. Тестовий репозиторій mcpotato/42-eicar-street блокується від завантаження, оскільки попередження містить перелік небезпечних файлів і підтверджує, що їх ніколи не завантажували. Хоча потенційні проблеми безпеки мають менш ніж 1% моделей Hugging Face, Unsloth створює додаткові процеси безпеки, що демонструє, наскільки надійним стає продукт Unsloth Studio як приклад переваг відкритого коду.

3. Перевіряйте залежність зсередини

Після висновків з інциденту LiteLLM стало зрозуміло, що самих рекомендаційних перевірок недостатньо: пакет може мати знайому назву та поставити шкідливий реліз ще до появи будь-якого попередження. Сканери вмісту пакетів Unsloth перевіряють сам архів, шукаючи доступ до облікових даних, обфусковані корисні навантаження, виконувані файли запуску та поведінку із завантаженням і виконанням під час встановлення. Сканування Python охоплює оголошені та транзитивні залежності. Сканер npm перевіряє завантажені tar-архіви, не запускаючи їхні сценарії життєвого циклу встановлення. Змінене корисне навантаження повторно відкриває виявлену проблему, а не успадковує постійний виняток, тому рекомендаційні сканування Unsloth повідомляють про проблеми, але не блокують їх; примусовим рівнем є перевірка вмісту. Лише пакети з білого списку можуть запускати сценарії, а npm відхиляє пакети, опубліковані менш ніж 7 днів тому. CI завершується помилкою, якщо невперевірений пакет намагається запустити такий сценарій. Для встановлення використовуються lock-файли та 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 працюють паралельно зі скануванням вмісту. У коментарях самого робочого процесу аудиту зазначено, що він навмисно уникає Trivy через попередню компрометацію у 2026 році.

4. Пісочниця має довести свою надійність

Перевірка пісочниць стала особливо важливою в епоху ШІ та моделювання, тому встановлений двійковий файл пісочниці — це лише початок, а не гарантія. Unsloth Studio запускає інструменти всередині пісочниць на рівні операційної системи: bubblewrap у Linux, Seatbelt у macOS і MXC у Windows. У Linux застосунок перевіряє, що двійковий файл bubblewrap і його батьківські каталоги належать системі та не доступні для запису групі або всім користувачам. Потім, згідно з репозиторієм, він перевіряє межі ізоляції. Чи може код у пісочниці прочитати контрольний файл хоста? Перейти до нього через символічне посилання робочого простору? Записати дані за межами робочого простору? Перевірка також підтверджує, що легітимні операції з робочим простором і дочірніми процесами продовжують працювати.

Користувачі й надалі мають вибір і можуть обрати режим схвалення: ask, auto або full. В автоматичному режимі мережеві та файлові імпорти позначаються для схвалення, а шляхи до файлів потребують дозволу. Небезпечні команди оболонки блокуються безпосередньо. Запити інструментів містять кнопки «Дозволити», «Завжди дозволяти» та «Відхилити». Сувора політика відмовляється від виконання інструменту, якщо ізоляція ОС недоступна або необхідна перевірка робочого простору не завершена. Політика з дозволами може перейти до програмних засобів захисту, і запис виконання це зазначає. Кожен запис містить інформацію про серверну частину, статус ізоляції, обмеження та результат очищення. HTML- і MCP-артефакти відображаються в фреймах із пісочницею із власною політикою безпеки вмісту.

Пісочниця Linux дозволяє мережевий доступ, має доступ із правом запису до кешу моделей і використовує спільне з хостом ядро. У поєднанні з мережевими обмеженнями та жорстко обмеженими обліковими даними цей процес слугує фінальною перевіркою.

Віддалений доступ і застосунок для комп’ютерів

Підтримка кількох користувачів у застосунку також дає змогу використовувати керовані облікові записи: кожен користувач бачить лише власні папки й ніколи не отримує токен Hugging Face власника. Керовані облікові записи потребують дозволу власника для використання моделей і не можуть запускати код із репозиторіїв. Нещодавно Unsloth оголосила про співпрацю з Jev і користувачами, які керують власною моделлю ухвалення рішень.

Робочий процес аудиту безпеки Unsloth використовує дозволи репозиторію лише для читання та облікові дані перевірки, які не зберігаються. Кожну дію GitHub зафіксовано на повному хеші коміту, а списки дозволених зовнішніх мережевих з’єднань блокують неочікуваний вихідний трафік. CodeQL охоплює Python, JavaScript/TypeScript, Rust і GitHub Actions. Unsloth повідомляє, що використовує Codex Security і повторні перевірки Codex під час розробки для виявлення проблем безпеки та помилок.

Доступ до бібліотеки та зміни

Основна бібліотека Unsloth також має цільове посилення захисту завдяки обробці власних типів даних, яка використовує фіксовану таблицю відповідностей замість оцінювання виразів. Успадковані виконувані поля конфігурації санітизуються, а регресійні тести захищають це виправлення. Тести проміжного програмного забезпечення Studio відхиляють надмірні фрагментовані запити, виявляючи випадки, які одна лише перевірка Content-Length могла б пропустити; релізи для комп’ютерів також проходять власні перевірки.

Попередньо зібрані двійкові файли llama.cpp перевіряються за дайджестами SHA-256, а підписи Windows проходять окремий аудит. Кожен реліз Unsloth Desktop сканується за допомогою VirusTotal. В одному опублікованому прикладі на момент сканування 70 постачальників не виявили жодної загрози. Unsloth зазначає, що кожен результат стосується лише файлів або коміту, перевірених у відповідний момент.

Що змінюється порівняно з простішим підходом

Функції	Рішення Unsloth
Довіряти репозиторію моделі за назвою	Прив’язувати схвалення до відбитка коду, включно з об’єднаними цілями адаптера та базової моделі
Вважати дозвіл на віддалений код єдиною перевіркою завантаження моделі	Додавати окремий контроль для позначених серіалізованих файлів у вибраному шляху завантаження
Виявити двійковий файл пісочниці й припустити наявність ізоляції	Перевіряти ізоляцію на хості та фіксувати фактичний рівень захисту
Покладатися лише на рекомендації щодо вразливостей	Застосовувати сканування вмісту пакетів із базовими лініями для конкретних виявлень і семиденною мінімальною давністю релізів npm
Запускати локальний ШІ від імені одного неявно довіреного користувача	Захищені паролем, обмежені за частотою багатокористувацькі облікові записи із зашифрованими ключами

Рисунок 2: П’ятикомпонентний контрольний список безпеки та конвеєра, який Unsloth застосовує до Studio і Desktop. Діаграма: Marktechpost.

Поза безпекою: покращення роботи з NPU

Відгуки, якими поділилися засновники Unsloth, вимагають більш детальних показників продуктивності на NPU, зокрема кількості токенів за секунду. Користувачі також хочуть мати можливість налаштовувати параметри завантаження моделі до запуску, як це вже можна робити для моделей GPU. Це заплановані покращення, а не підтверджені релізи, які мають забезпечити кращу видимість і контроль під час локального запуску моделей.

Переглянувши огляд Unsloth і виконавши статичний аналіз джерела репозиторію, ми охопили коміт 285d157a. Доступність функцій у релізах ґрунтується на інформації, наданій для цієї статті. Режими схвалення, пісочниці macOS і Windows, шифрування облікових даних, правила щодо віку релізів npm і перевірки застосунку для комп’ютерів описані в огляді. Схвалення, прив’язане до відбитка, перевірка пісочниці, записи виконання та пороги входу походять із репозиторію. Деякі засоби захисту належать Unsloth Studio і Desktop; сканування залежностей та обмеження аудиту містяться в робочому процесі розробки. Вони автоматично не захищають ноутбук, який імпортує окрему бібліотеку.

Основні висновки

Unsloth Studio прив’язує дозвіл на віддалений код до відбитка просканованого коду; змінений код потребує нового дозволу.
Вердикти Hugging Face щодо шкідливого програмного забезпечення блокують позначені файли ваг у шляху завантаження незалежно від trust_remote_code.
Інструменти можуть запускатися в пісочницях ОС (bubblewrap, Seatbelt, MXC); у Linux репозиторій показує, що Studio спочатку перевіряє ізоляцію.
Сканування вмісту пакетів завершує CI з помилкою при нових виявленнях високої або критичної тяжкості; npm відхиляє пакети віком до 7 днів.
Studio за замовчуванням захищена паролем і підтримує кількох користувачів, має обмеження частоти входу та зашифровані API-ключі.

Джерела

_{Примітка:}_{Дякуємо команді Unsloth за експертні коментарі та ресурси для цієї статті. Цю статтю підтримує Unsloth.}

Перекладено автоматично з англійської. Оригінал статті — за посиланням нижче.