Какво се случва, когато доверено хранилище за модели се промени? Unsloth Studio проверява отново, преди да стартира

Изводи от бета версията

След над 500 милиона изтегляния, години заявки от общността с отворен код и позиция сред водещите продукти в Hugging Face, Unsloth пуснаха своето настолно приложение в бета версия — Unsloth Studio. Unsloth прави дообучаването и стартирането на AI модели по-бързо, по-лесно и по-достъпно, включително локално на собствения ви хардуер. Приложението централизира функциите на едно място чрез Unsloth Studio, така че потребителите вече могат да използват инсталация от табло вместо ръчна инсталация.

Проектите с отворен код разчитат на други източници на код или платформи, а в случая с Unsloth, като ранен потребител на локалното моделиране, продуктът им комбинира свободата на платформата Hugging Face с възможностите за дообучаване на различните пакети на Unsloth.

След стартирането на Unsloth Studio компанията започна да обновява продукта си с бързи темпове за проект с отворен код, като същевременно се адаптира към бързо променящата се среда за сигурност в AI. Например компрометирани версии 1.82.7 и 1.82.8 на LiteLLM се появиха в PyPI чрез компрометиран скенер Trivy, изтеглен без фиксирана версия в CircleCI конвейера на LiteLLM, и разкриха идентификационните му данни за публикуване. PyPI бързо постави и двете версии под карантина в рамките на час, но инструментът за сигурност беше станал част от пътя на атаката и вече се използваше надолу по веригата. Unsloth бързо пусна обновления на продукта, за да се адаптира.

Месец по-късно се случи нещо друго, което определи сигурността на настолната версия на Unsloth: крадец на информация, скрит в хранилище на Hugging Face. Hugging Face, като водеща платформа за изтегляне и споделяне на модели, неволно хостваше хранилище с крадец на информация. Хранилището се представяше за версията на OpenAI Privacy Filter и копираше почти дословно картата на модела ѝ. Неговият loader.py изтегляше и стартираше крадец на информация в Windows. След това хранилището достигна №1 в класацията „Trending“ и показа около 244 000 изтегляния — числа, които според HiddenLayer почти сигурно са били завишени.

Тези два епизода помогнаха да се оформи базовото правило в продуктовата пътна карта на Unsloth за сигурност: действайте бързо.

Как Unsloth оформи сигурността на продукта

Още от самото начало това настолно приложение използва най-съвременните решения от света на отворения код и се адаптира бързо към променящата се среда. Unsloth установи протоколи, които да гарантират оптимална сигурност за крайните потребители. След мащабно издаване на версии, в навечерието на седмицата на AI с отворен код 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 прочита тези резултати и блокира маркираните файлове по пътя, по който избраният зареждащ механизъм би ги десериализирал. Това включва вложени части, посочени от индексите на теглата. То прочита резултата от сканирането, без да десериализира маркирания артефакт чрез unpickle. Проверката не е отказоустойчива по подразбиране. Според хранилището зареждането може да продължи, когато метаданните от сканирането не са налични или все още се обработват. Обикновените локални папки с модели не са обхванати. Минималното изискване на Unsloth за PyTorch 2.6+ означава, че .bin теглата се зареждат с weights_only=True, а поведението може да бъде тествано. Тестовото хранилище mcpotato/42-eicar-street е блокирано за зареждане, тъй като предупреждението посочва небезопасните файлове и потвърждава, че те никога не са били изтегляни. Макар че по-малко от 1% от моделите в Hugging Face имат потенциални проблеми със сигурността, Unsloth създава допълнителни процеси за сигурност, което показва колко надежден става продуктът Unsloth Studio и представлява доказателство за силата на отворения код.

3. Погледнете вътре в зависимостта

След поуките от инцидента с LiteLLM е ясно, че информационните проверки не са достатъчни, защото един пакет може да носи познато име и да разпространи злонамерена версия, преди да съществува каквото и да е предупреждение. Скенерите на Unsloth за съдържанието на пакетите проверяват самия архив за достъп до идентификационни данни, обфускирани полезни товари, изпълними стартови файлове и поведение за изтегляне и изпълнение по време на инсталацията. Python сканирането обхваща декларираните и транзитивните зависимости. npm скенерът проверява изтеглените tarball файлове, без да изпълнява скриптовете от жизнения цикъл на инсталацията им. Промененият полезен товар отваря отново констатацията, вместо да наследява постоянно освобождаване, така че информационните сканирания на Unsloth докладват, но не блокират; констатациите от проверката на съдържанието са задължителният слой, а Unsloth добавя правила за релевантност върху него. Само пакетите от списъка с разрешени пакети могат да изпълняват скриптове, а npm инсталациите отхвърлят пакети, публикувани преди по-малко от 7 дни. CI се проваля, ако непроверен пакет се опита да изпълни такъв скрипт. Инсталациите използват lockfile файлове и 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. Изолираната среда трябва да се докаже

Проверката на изолираната среда стана особено важна в епохата на AI и моделирането, така че наличието на инсталиран бинарен файл за изолирана среда е само начална точка, а не гаранция. Unsloth Studio изпълнява инструментите в изолирани среди на ниво операционна система: bubblewrap в Linux, Seatbelt в macOS и MXC в Windows. В Linux приложението проверява дали бинарният файл bubblewrap и родителските му директории са собственост на системата и не могат да бъдат записвани от групата или всички потребители. След това, според хранилището, то проверява границата. Може ли кодът в изолираната среда да прочете sentinel файл на хоста? Може ли да проследи символна връзка от работното пространство до него? Може ли да записва извън работното пространство? Проверката потвърждава също, че легитимните операции в работното пространство и операциите на дъщерните процеси продължават да работят.

Потребителите все още имат възможности и могат да изберат режим на одобрение: ask, auto или full. В автоматичен режим мрежовият достъп и импортирането на файловата система се маркират за одобрение, а пътищата към файлове изискват одобрение. Опасните shell команди се блокират директно. Заявките към инструментите показват бутоните Allow, Always allow и Deny. Строгата политика отказва изпълнение на инструменти, когато изолацията на ниво ОС не е налична или необходимата проверка на работното пространство не е завършена. По-разрешителната политика може да премине към софтуерни защити, а записът за изпълнение посочва това. Всеки запис посочва бекенда, статуса на изолацията, ограниченията и резултата от почистването. HTML и MCP артефактите се визуализират в изолирани рамки със собствена политика за сигурност на съдържанието.

Изолираната среда в Linux позволява мрежов достъп, има достъп за запис до кеша на моделите и споделя ядрото на хоста. В комбинация с мрежови ограничения и строго ограничени идентификационни данни този процес служи като финална проверка.

Отдалечен достъп и настолно приложение

Наличието на множество потребители в приложението позволява и управлявани акаунти: всеки потребител вижда само собствените си папки и никога токена на собственика в Hugging Face. Управляваните акаунти се нуждаят от разрешение от собственика, за да използват модели, и са блокирани от изпълнение на код от хранилища. Наскоро Unsloth обяви, че работи с Jev и потребители, управляващи собствен модел за вземане на решения.

Работният процес за одит на сигурността на Unsloth използва разрешения само за четене на хранилището и идентификационни данни за checkout, които не се съхраняват. Всеки GitHub Action е фиксиран към пълен хеш на commit, а списъците с разрешени изходящи мрежови връзки блокират неочаквания изходящ трафик. CodeQL обхваща Python, JavaScript/TypeScript, Rust и GitHub Actions. Unsloth заявява, че използва Codex Security и многократни проверки с Codex по време на разработката, за да открива проблеми със сигурността и грешки.

Достъп до библиотеката и промени

Основната библиотека на Unsloth също е подсилена целево чрез обработка на персонализирани типове данни, която използва фиксирана таблица за справка вместо оценяване на изрази. Наследените изпълними полета за конфигурация се дезинфекцират, а регресионните тестове защитават поправката. Тестовете на междинния софтуер на Studio отхвърлят прекалено големи заявки на части, като улавят случаи, които една проверка само на Content-Length би пропуснала; настолните версии също получават собствени проверки.

Предварително компилираните бинарни файлове на llama.cpp се проверяват спрямо SHA-256 дайджести, а подписите за Windows се одитират отделно. Всяка версия на Unsloth Desktop се сканира с VirusTotal. В един публикуван пример по време на сканирането са отчетени 0 засичания от 70 доставчици. Unsloth отбелязва, че всеки резултат се отнася само до файловете или commit-а, проверени в съответния момент.

Какво се променя спрямо по-простия подход

Функции	Решението на Unsloth
Доверие на хранилището на модела въз основа на името	Обвързване на одобрението с отпечатък на кода, включително комбинираните цели на адаптера и базовия модел
Третиране на съгласието за отдалечен код като единствена проверка при зареждане на модела	Добавяне на отделна проверка за маркирани сериализирани файлове по избрания път за зареждане
Откриване на бинарен файл за изолирана среда и приемане, че изолацията е налице	Проверка на изолацията на хоста и записване на ефективното ниво на защита
Разчитане единствено на информационни предупреждения за уязвимости	Задължително сканиране на съдържанието на пакетите със специфични за констатациите базови линии и изискване за 7-дневна възраст на npm версиите
Стартиране на локален AI с 1 имплицитно доверен потребител	Защитени с парола, ограничени по честота акаунти за множество потребители с криптирани ключове

Фигура 2: Контролният списък с 5 точки за сигурност и конвейер, който Unsloth прилага към Studio и Desktop. Диаграма: Marktechpost.

Отвъд сигурността: подобряване на изживяването с NPU

Обратната връзка, споделена от основателите на Unsloth, призовава за по-богати показатели за производителността на NPU, включително токени в секунда. Приложението също така се нуждае от възможност за конфигуриране на настройките за зареждане на модела преди стартиране, каквато вече съществува при GPU моделите. Това са желани подобрения, а не потвърдени версии, които биха осигурили по-добра видимост и контрол при локално стартиране на модели.

При прегледа на обзора на Unsloth и статичен преглед на изходния код на хранилището разгледахме commit 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.}

Преведено автоматично от английски. Оригиналната статия е на връзката по-долу.