Hugging Face e ModelAudit: pesquisa revelou os limites da proteção integrada de modelos ML

Исследователь сравнил встроенные проверки безопасности Hugging Face с внешним сканером ModelAudit и получил не самый очевидный результат: один инструмент может видеть больше рискованных сигналов, но при этом создавать много шума. Главный вывод статьи — число критических алертов само по себе почти ничего не говорит о том, насколько модель действительно зловредна.

Как устроили тест В первом эксперименте автор взял не весь

Hugging Face, а подмножество репозиториев с наиболее рискованными форматами хранения моделей. В выборку попадали только открытые модели, где были файлы вроде `.pkl`, `.pickle`, `.dill`, `.pt`, `.pth`, `.ckpt`, `.bin`, `.joblib`, `.npy` и `.npz`. Дополнительно отсекались слишком большие репозитории и слишком популярные модели: суммарный размер ограничили 1 ГБ, а число загрузок за месяц — 10 тысячами. Идея простая: если искать реальные проблемы, разумнее сначала смотреть туда, где вероятность опасной сериализации выше.

• В первом наборе просканировали 246 моделей ModelAudit нашёл 271 критическое предупреждение Хотя бы один критический алерт получили 34 модели * Для сравнения брались именно репозитории, а не отдельные чекпоинты внутри них Но уже на старте выяснилось, что большое количество находок не равно качеству детекта. Самой «богатой» на сработки оказалась модель Ultralytics/YOLO11: она получила 728 предупреждений, из них 35 критических. На бумаге это выглядит как сильный сигнал о компрометации, но ручной разбор показал более скучную картину. Значительная часть критических флагов была завязана на стандартные элементы Python, которые могут встречаться и в легитимных моделях. То есть сканер правильно замечал потенциально опасные паттерны, но слишком часто трактовал их как прямое доказательство атаки.

Где шумят правила Разбор YOLO11 хорошо показал слабое место статического анализа.

Часть сработок шла по `pickle_check` из-за `__builtin__.getattr`, а часть — по `pytorch_zip_check` из-за `__builtin__.set` и похожих признаков.

Проблема в том, что `getattr` действительно может использоваться в вредоносных цепочках для обхода примитивных правил, но это же обычная функция Python, которая встречается и в нормальном коде. С `set` ситуация ещё показательнее: один внутренний сканер ModelAudit считает такой импорт допустимым, а другой может пометить всё пространство `builtin` как подозрительное. Именно поэтому автор отдельно подчёркивает: высокая плотность даже критических предупреждений — это повод для ручного триажа, а не приговор модели.

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

«Не так я себе всё представлял, когда мы начинали»

Сравнение с

Hugging Face Во втором эксперименте автор сменил фокус и собрал список моделей, которые сами авторы репозиториев уже помечали как malicious, exploit, ace, deserialization или poc. После дополнительной фильтрации через LLM этот набор прогнали через ModelAudit и сопоставили результаты с встроенными статусами Hugging Face. Базовое сравнение дало довольно сильное совпадение: 154 репозитория обе стороны сочли опасными, а 49 — безопасными.

При этом нашлись 14 случаев, где ModelAudit видел проблему, а Hugging Face ничего подозрительного не показывал. Самый важный нюанс здесь в том, что часть полезных сигналов у ModelAudit живёт не только на уровнях warning и critical. В статье приводится пример `jossefharush/gpt2-rs`, где алерт уровня INFO содержал признаки сетевой активности и ссылку на Pastebin.

Дальнейшая проверка показала, что по этой ссылке лежит бэкдор, отправляющий злоумышленнику результаты выполнения команд на машине жертвы. То есть «информационное» сообщение в конкретном кейсе оказалось содержательно важнее многих громких критических флагов из первого эксперимента. Отдельно автор разобрал и обратные расхождения, когда Hugging Face сигнализировал об опасности, а ModelAudit пропускал модель.

Изначально такие пропуски были у версии 0.2.24, но после обновлений до 0.

2.28, а затем до 0.2.

31 эти случаи исчезли. Финальная картина получилась такой: все репозитории, которые Hugging Face в итоге считал опасными, ловились и ModelAudit, а сверх этого у внешнего сканера оставалось ещё 17 репозиториев с опасными сигналами, которых не было во встроенных предупреждениях HF.

Что это значит

Один сканер не решает проблему безопасности ML-артефактов, даже если он выглядит самым зрелым в своём классе. Статья про Hugging Face и ModelAudit показывает более полезную мысль: хорошие результаты даёт не ставка на один «лучший» инструмент, а сочетание нескольких проверок, регулярных обновлений правил и обязательного ручного разбора самых громких сработок.