Локальный запуск открытых моделей давно перестал быть безопасным по умолчанию: файлы и код тянутся с внешних площадок, а проверять их вручную никто не хочет. Unsloth опубликовала обзор безопасности Unsloth Studio и Unsloth Desktop, где описала четыре контрольные точки, через которые проходит любой запуск модели. Материал вышел к неделе открытого ИИ и опирается на коммит 285d157a репозитория проекта. Если вы уже разворачивали модели локально — например, по инструкции Hermes Desktop, — то знаете, что удобство установки и безопасность здесь расходятся.
Случай с инфостилером на Hugging Face
Поводом для разговора стал реальный инцидент: в репозитории Hugging Face прятался инфостилер. Репозиторий выдавал себя за релиз OpenAI Privacy Filter и почти дословно копировал его карточку модели. Файл loader.py скачивал и запускал инфостилер на Windows. Репозиторий вышел на первое место в трендах и набрал около 244 000 загрузок — по данным HiddenLayer, эти цифры почти наверняка были завышены.
Именно поэтому проверки в момент загрузки, а не только на этапе публикации, стали обязательным слоем защиты.
Первая проверка: одобрение привязано к коду, а не к имени
Unsloth Studio сканирует код модели и сохраняет его отпечаток. При каждой загрузке отпечаток сверяется заново вместе с версией сканера. Сохранённое одобрение убирает повторный диалог, но не отменяет нового сканирования: изменённый код требует свежего согласия. Если модель загружается как адаптер плюс база, проверяются оба репозитория, включая токенизатор, процессор и вложенную конфигурацию.
Находки высокой и средней критичности требуют одобрения, совпадающего с текущим отпечатком. Если удалённый код нужно проверить, но получить его не удаётся, загрузка блокируется. Доверенный издатель не получает исключения: остановить может даже репозиторий первой стороны. Сканер ищет конкретное поведение — открытие обратного шелла, обращения к эндпоинтам облачных метаданных, кражу учётных данных.
Важная оговорка: этот шлюз не является песочницей. После одобрения удалённый код модели выполняется без ограничений от имени пользователя Studio, а статические шаблоны можно обойти. Шлюз уже срабатывал на популярных моделях: deepseek-ai/deepseek-ocr запрашивает одобрение из-за находки exec/eval, moonshotai/Kimi-VL-A3B-Instruct — из-за продвинутой обфускации. В своих адаптированных репозиториях unsloth/DeepSeek-OCR и unsloth/DeepSeek-OCR-2 проект убрал вызовы eval и другие проблемные участки.
Вторая проверка: опасные веса блокируются отдельно
Небезопасные сериализованные веса, включая вредоносные pickle-файлы, — второй путь к выполнению кода. Studio проверяет их отдельно от согласия на удалённый код. Hugging Face сам сканирует репозитории на вредоносное ПО и показывает предупреждения на странице модели — Studio читает эти результаты и блокирует помеченные файлы на том пути, по которому выбранный загрузчик будет их десериализовать, включая вложенные шарды, на которые ссылаются индексы весов. Результат сканирования читается без распаковки помеченного артефакта.
Шлюз не работает по принципу fail-closed: согласно репозиторию, загрузка может продолжиться, если метаданные сканирования недоступны или ещё не готовы. Обычные локальные папки с моделями не покрываются. Минимальная версия PyTorch 2.6+ означает, что веса .bin загружаются с параметром weights_only=True, и такое поведение можно проверить тестом. Тестовый репозиторий mcpotato/42-eicar-street блокируется: предупреждение перечисляет небезопасные файлы и подтверждает, что они так и не были скачаны. По данным проекта, потенциальные проблемы безопасности есть менее чем у 1% моделей на Hugging Face.
Третья проверка: содержимое зависимостей
Компрометация LiteLLM в марте 2026 года показала, что консультационных проверок недостаточно: пакет может носить знакомое имя и выпустить вредоносную версию раньше, чем появится предупреждение. Сканеры содержимого пакетов в Unsloth изучают сам архив — ищут доступ к учётным данным, обфусцированные полезные нагрузки, исполняемые файлы автозапуска и поведение «скачать и выполнить» на этапе установки. Python-сканер покрывает объявленные и транзитивные зависимости, npm-сканер проверяет скачанные tarball-архивы, не запуская их установочные скрипты. Изменённая полезная нагрузка вновь открывает находку вместо того, чтобы унаследовать бессрочное исключение.
Консультационные сканы только сообщают, но не блокируют — принудительный слой составляют именно находки по содержимому. Поверх них добавлены правила релевантности: запускать скрипты разрешено только пакетам из allowlist, а 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. Комментарии самого workflow аудита указывают, что он намеренно избегает Trivy из-за более ранней компрометации в 2026 году.
Четвёртая проверка: песочница должна доказать, что она работает
Установленный бинарник песочницы — это отправная точка, а не гарантия. Unsloth Studio запускает инструменты в песочницах уровня ОС: bubblewrap в Linux, Seatbelt в macOS и MXC в Windows. В Linux проверяется, что бинарник bubblewrap и его родительские каталоги принадлежат системе и не доступны на запись группе и остальным. Затем, согласно репозиторию, проверяются границы: может ли код в песочнице прочитать сигнальный файл хоста, перейти по символической ссылке рабочей области к нему, записать что-то вне рабочей области. Заодно подтверждается, что легитимные операции с рабочей областью и дочерними процессами по-прежнему работают.
Пользователь выбирает режим одобрения: ask, auto или full. В auto-режиме сетевые и файловые импорты помечаются для одобрения, пути к файлам тоже требуют подтверждения, а опасные shell-команды блокируются сразу. Запросы инструментов показывают кнопки Allow, Always allow и Deny. Строгая политика отказывает в запуске инструмента, если изоляция ОС недоступна или обязательная проверка рабочей области не завершена. Разрешающая политика может откатиться к программным средствам защиты, и запись о выполнении это отражает. Каждая запись перечисляет бэкенд, статус изоляции, ограничения и результат очистки. Артефакты HTML и MCP отображаются в изолированных фреймах с собственной политикой Content Security Policy.
Linux-песочница разрешает сетевой доступ, имеет доступ на запись к кешу моделей и делит ядро с хостом. В паре с сетевыми ограничениями и узко ограниченными учётными данными это и есть финальная проверка.
Многопользовательский режим и проверки релизов
Несколько пользователей в приложении получают управляемые аккаунты: каждый видит только свои папки и никогда — токен Hugging Face владельца. Управляемым аккаунтам нужно разрешение владельца на использование моделей, и им запрещено запускать код репозиториев.
Workflow аудита безопасности использует права только на чтение и не сохраняемые учётные данные для checkout. Каждое действие GitHub Action привязано к полному хешу коммита, а allowlist исходящих соединений блокирует неожиданный трафик. CodeQL покрывает Python, JavaScript/TypeScript, Rust и GitHub Actions. Проект заявляет, что во время разработки запускает Codex Security и повторные проверки Codex.
Ядро библиотеки тоже усилено точечно: пользовательская обработка типов данных идёт через фиксированную таблицу поиска вместо вычисления выражений, наследуемые исполняемые поля конфигурации очищаются, а регрессионные тесты охраняют исправление. Тесты middleware в Studio отклоняют слишком большие чанковые запросы — случай, который одна проверка Content-Length пропустила бы. Готовые бинарники llama.cpp сверяются по дайджестам SHA-256, подписи Windows проверяются отдельно. Каждый релиз Unsloth Desktop сканируется через VirusTotal; в одном опубликованном примере было 0 детектов у 70 вендоров на момент сканирования.
Стоит помнить о границах: часть защит относится к Unsloth Studio и Desktop, а сканирование зависимостей и ограничения аудита живут в процессе разработки. Они не защищают автоматически блокнот, который импортирует отдельную библиотеку.
Что это значит для локального запуска
Подход Unsloth меняет несколько привычек. Вместо доверия репозиторию по имени одобрение привязывается к отпечатку кода, включая комбинированные цели «адаптер плюс база». Вместо согласия на удалённый код как единственной проверки появляется отдельный шлюз для помеченных сериализованных файлов на выбранном пути загрузки. Вместо обнаружения бинарника песочницы и предположения об изоляции — проверка изоляции на хосте и запись фактического уровня защиты. Вместо опоры только на консультации по уязвимостям — принудительные проверки содержимого пакетов с базовыми замерами и правилом 7-дневного возраста для npm. Вместо одного неявно доверенного пользователя — многопользовательские аккаунты с паролем, ограничением частоты попыток и шифрованными ключами.
Отдельно основатели Unsloth собирают обратную связь по работе с NPU: пользователи просят более богатые метрики производительности, включая токены в секунду, и возможность настраивать параметры загрузки модели до запуска — так, как это уже разрешено для GPU-моделей. Это запросы на улучшения, а не подтверждённые релизы. Тем, кто выбирает между плотной моделью и смесью экспертов для локального запуска, пригодится разбор Dense против MoE: чем больше компонентов в сборке, тем важнее проверять каждый из них.
Частые вопросы
Кого касается эта новость?
Всех, кто запускает открытые модели локально: от разработчиков, тянущих веса с Hugging Face, до администраторов рабочих станций с GPU. Описанные проверки встроены в Unsloth Studio и Unsloth Desktop.
Что именно проверяется при загрузке модели?
Четыре вещи: отпечаток кода модели, помеченные сериализованные файлы весов, содержимое пакетов-зависимостей и работоспособность песочницы ОС.
Почему одобрение кода перестаёт действовать?
Оно привязано к отпечатку просканированного кода. Если репозиторий изменился, отпечаток другой, и требуется новое согласие — даже если раньше вы уже нажимали «одобрить».
Доверенный издатель обходит проверки?
Нет. По описанию проекта, репозиторий первой стороны тоже может быть остановлен, если сканер найдёт проблемы высокой или средней критичности.
Что будет, если метаданные сканирования Hugging Face недоступны?
Шлюз не работает по принципу fail-closed: загрузка может продолжиться, если результаты сканирования недоступны или ещё не готовы. Обычные локальные папки с моделями этот шлюз не покрывает.
Заменяет ли сканер кода песочницу?
Нет. Это разные слои: после одобрения удалённый код модели выполняется без ограничений от имени пользователя Studio, а статические шаблоны можно обойти.
Какие песочницы используются на разных платформах?
bubblewrap в Linux, Seatbelt в macOS и MXC в Windows. В Linux перед запуском проверяется владение бинарником и границы изоляции.
Что означают режимы одобрения ask, auto и full?
В auto-режиме сетевые и файловые импорты и пути к файлам требуют подтверждения, а опасные shell-команды блокируются сразу. Строгая политика отказывает в запуске инструмента, если изоляция ОС недоступна.
Есть ли защита от свежих вредоносных пакетов в npm?
Да, установка отклоняет пакеты, опубликованные менее 7 дней назад, запускать скрипты разрешено только пакетам из allowlist, а CI падает при попытке неотсмотренного пакета запустить скрипт.
Видят ли другие пользователи приложения мой токен Hugging Face?
Нет. Управляемые аккаунты видят только свои папки, а токен владельца им недоступен; для использования моделей нужно разрешение владельца.
Защищает ли это блокнот с отдельной библиотекой Unsloth?
Нет. Часть защит относится к Studio и Desktop, а сканирование зависимостей и ограничения аудита работают в процессе разработки и не переносятся автоматически на блокнот, импортирующий standalone-библиотеку.
Источник: marktechpost.com