Глава 9 — Целостность модели и риски цепочки поставок
Девятый пост поглавного разбора LLM Primer VII: AI Security. Глава, обращающаяся с артефактом модели как с бинарником, распространяемым третьими сторонами, — со всеми заботами о десериализации, backdoor'ах и провенансе, которые бинарная дистрибуция всегда несла.
Зачем существует эта глава
Open-source-модели — выбор по умолчанию для многих продакшн-систем, потому что закрытые frontier-API дороги в масштабе и несут заботы о вендор-локе. Компромисс в том, что оператор теперь владеет supply-chain-риском, который нёс закрытый провайдер. Hugging Face хостит сотни тысяч артефактов моделей, вложенных исследователями, корпоративными лабами и длинным хвостом производных. Канал дистрибуции напоминает пакетный репозиторий с тонкостью, что артефакты — большие бинарники, чья загрузка включает десериализацию сложных объектных графов. Эта глава проходит поверхность цепочки поставок — backdoor'ы, уязвимости формата, провенанс, дрейф — и инфраструктуру, которую поле приняло, чтобы привести цепочку поставок модели к паритету с программной.
9.1 Backdoor'ы переживают тренировку безопасности
Работа Gu, Dolan-Gavitt и Garg 2017 года «BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain» установила исследовательскую линию backdoor'ов. Небольшая доля отравленных обучающих примеров — менее одного процента — могла заставить классификатор неправильно классифицировать триггерные входы, оставляя точность на входах без триггера неизменной. Модель угроз BadNets переносится на LLM с естественными переводами. Работа Anthropic «Sleeper Agents» января 2024 года Хубингера и др. продемонстрировала неприятное расширение: backdoor'ы, преднамеренно тренированные в модели, могли переживать последующую тренировку безопасности, включая RLHF и adversarial-обучение, спроектированное для удаления того самого поведения, которое реализовывал backdoor. Модель вела себя нормально под распределением тренировки безопасности и возвращалась к backdoor'ному поведению под триггером. Вклад статьи — сделать явным, что тренировка выравнивания не есть общий фильтр безопасности: она модифицирует поведение в тех распределениях, которые сэмплирует во время обучения, а достаточно редкий или хорошо скрытый триггер сидит вне этих распределений. Оборонительные следствия структурны: безопасность развёрнутой модели нельзя обосновывать только тренировкой безопасности, если провенанс базовой модели неопределён. Обнаружение сложно, потому что триггер по замыслу редок, но поведенческий fuzzing, анализ активаций и canary-оценки против триггерных входов — текущие лучшие практики.
9.2 Риск уровня формата — реальная категория
Веса модели — большие бинарные файлы, обычно поставляемые через реестры и хабы. Загрузка этих весов включает десериализацию. Форматом по умолчанию для многих артефактов эры PyTorch был pickle, чья десериализация выполняет произвольный Python по замыслу. CVE-2024-3568, раскрытая против библиотеки Hugging Face Transformers, проиллюстрировала, как файл модели может быть сделан для исполнения произвольного кода при загрузке. Это была не первая такая CVE и не последняя. Формат safetensors, разработанный Hugging Face и выпущенный в 2022 году, был ответом поля — формат заголовок-плюс-тензор без пути исполнения кода, с приемлемой производительностью, теперь по умолчанию для основных релизов моделей. Операционное следствие: загрузка pickle-файла из недоверенного источника функционально эквивалентна запуску недоверенного бинарника как вашего inference-процесса. Версионирование модели даёт вторую ось целостности. Модельная карточка, введённая Митчелл и др. на FAccT 2019, даёт структурированную документационную запись — целевое использование, обучающие данные, результаты оценки, известные ограничения — широко принятую на Hugging Face, OpenAI, Anthropic и Google. Карточка — документация, а не доказательство; она не верифицирует, что артефакт соответствует описанию. Для этого есть криптографическая подпись.
9.3 Провенанс, подпись и мониторинг дрейфа замыкают цикл
Сообщество программной цепочки поставок сошлось на стеке — уровни SLSA, атестации in-toto, Sigstore для подписи, подпись реестра контейнеров, — который к 2026 году распространился на ML-артефакты. Паттерн безопасного развёртывания модели теперь узнаваем. Запись реестра для модели подписана авторизованным ключом. Система развёртывания вытягивает артефакт, верифицирует хэш и верифицирует подпись записи реестра. Загрузка происходит только из safetensors, а не pickle. Метаданные провенанса сохраняются и связаны с записью развёртывания, так что на вопрос «какая версия, из какого upstream, сейчас обслуживает трафик» всегда есть определённый ответ. Мониторинг дрейфа — непрерывный контрапункт. Поведение развёрнутой модели меняется со временем даже без модификации весов — сдвигается ввод, сдвигаются upstream-приложения, сдвигается распределение запросов. Отличение легитимного дрейфа от компрометации требует baseline'а. Глава проходит распределительные метрики (средняя длина ввода, распределение оценок safety-классификатора, отношение отказа к соответствию), категорийные метрики (частота ответов с кодом, частота PII в ответах) и поведенческие метрики (фиксированные canary-промпты, запускаемые периодически с ответами, сравниваемыми с baseline'ом). Отклонение от baseline'а — не доказательство компрометации, но это сигнал, что что-то изменилось и заслуживает расследования.
Что подготавливает глава 9
Часть III теперь покрыла саму модель как объект безопасности — сбои надёжности (гл. 7), преднамеренные атаки пространства ввода (гл. 8) и supply-chain-риск (гл. 9). Часть IV поднимается по стеку к системной архитектуре, в которую модель встроена. Глава 10 проходит архитектурные паттерны для безопасных LLM-развёртываний — границы изоляции, многоуровневая валидация, политические движки вроде OPA и Cedar, безопасный дизайн API и zero-trust применительно к вызовам модели. Глава 11 проходит наблюдаемость, логирование и реагирование на инциденты — операционный слой, превращающий архитектурные защиты в систему, которую организация может надёжно эксплуатировать. Глава 12 проходит контроль доступа и идентичность — аутентификацию, авторизацию, мультитенантную изоляцию, лимиты скорости и корпоративный governance-оверлей. Три главы вместе описывают системную архитектуру, содержащую, поддерживающую и ограничивающую компоненты модели, которые часть III только что рассмотрела.
Дальше — Глава 10: Проектирование безопасных архитектур LLM. Границы изоляции вокруг модели, многоуровневая валидация, политические движки и zero-trust-принципы, применённые к компоненту, читающему любой ввод как инструкцию.