Что происходит, когда доверенный репозиторий моделей меняется? 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. Затем репозиторий занял первое место в рейтинге трендов и показал около 244 000 загрузок — по словам HiddenLayer, эти цифры почти наверняка были завышены.

Эти два эпизода помогли сформировать основу дорожной карты безопасности продукта 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 считывает эти результаты и блокирует отмеченные файлы в том пути, где выбранный загрузчик выполнял бы десериализацию. Сюда входят и вложенные фрагменты, указанные в индексах весов. Приложение считывает результат сканирования, не выполняя распаковку pickle отмеченного объекта. Шлюз не работает по принципу безусловной блокировки. Согласно репозиторию, загрузка может продолжиться, если метаданные сканирования недоступны или проверка еще не завершена. Обычные локальные папки моделей не охватываются этой защитой. Минимальное требование 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 сообщают о проблемах, но не блокируют их; принудительно применяемым уровнем являются результаты проверки содержимого, поверх которого 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. В режиме auto сетевые импорты и импорты файловой системы требуют одобрения, как и пути к файлам. Опасные команды оболочки блокируются полностью. Запросы инструментов показывают кнопки «Разрешить», «Всегда разрешать» и «Запретить». Строгая политика отказывается выполнять инструменты, если изоляция ОС недоступна или обязательная проверка рабочей области не завершена. Разрешительная политика может перейти к программным средствам защиты, и это отражается в записи о выполнении. Каждая запись содержит сведения о серверной части, состоянии изоляции, ограничениях и результате очистки. Артефакты HTML и MCP отображаются в фреймах песочницы с собственной политикой безопасности содержимого.

Песочница Linux разрешает сетевой доступ, предоставляет доступ с правом записи к кэшу моделей и использует общее с хостом ядро. В сочетании с сетевыми ограничениями и тщательно ограниченными учетными данными этот процесс служит финальной контрольной точкой.

Удаленный доступ и настольное приложение

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

Рабочий процесс security-audit Unsloth использует разрешения репозитория только для чтения и учетные данные checkout, которые не сохраняются. Каждое действие 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-релиза в 7 дней
Запускать локальный ИИ от имени 1 неявно доверенного пользователя	Использовать защищенные паролем, ограниченные по частоте многопользовательские учетные записи с зашифрованными ключами

Рисунок 2: Контрольный список из 5 пунктов для безопасности и конвейера, который 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.}

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