Гайд · Безопасная разработка AI

Цепочка поставки AI: что проверять до доставки модели в промышленную среду

Артефакты, зависимости, происхождение и воспроизводимый контур поставки моделей, адаптеров и инструментов.

Иллюстрация к материалу «Цепочка поставки AI: что проверять до доставки модели в промышленную среду»
Темы:цепочка поставкиотравление моделейDevSecOpsпроверка происхождения

Цепочка поставки AI включает модели, библиотеки, контейнеры, адаптеры, наборы данных, эмбеддинги и подключаемые инструменты. Любой из этих объектов способен изменить поведение системы ещё до того, как пользователь отправит первый запрос. Поэтому происхождение и проверяемость должны быть частью обычного процесса поставки.

01

Фиксируйте, что именно поставляется

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

02

Используйте утверждённые источники

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

03

Разделите проверку и выпуск

Новый артефакт сначала попадает в контролируемую среду оценки. Там проверяют совместимость, права доступа, ожидаемые защитные сценарии и возможность отката. Только после утверждения он получает путь в промышленную среду. Разделение сред уменьшает вероятность того, что экспериментальный компонент незаметно получит доступ к рабочим данным.

04

Подготовьте отзыв заранее

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

Граница применимости. Это защитно-ориентированное объяснение, а не гарантия предотвращения инцидентов. Контроли следует адаптировать через моделирование угроз, требования к данным и процессы реагирования вашей организации.

Продолжите исследование

Связанные риски

Карточки связывают материал с конкретными угрозами, признаками и мерами защиты на интерактивной карте.

A19 · Критический

Model poisoning / backdoored model

Модель, данные, adapter или dependency попадают в жизненный цикл без достаточной проверки происхождения и целостности.

Открыть карточку
A20 · Высокий

Malicious model deserialization / pickle

Модель, данные, adapter или dependency попадают в жизненный цикл без достаточной проверки происхождения и целостности.

Открыть карточку
A21 · Высокий

Typosquatted or fake model repository

Модель, данные, adapter или dependency попадают в жизненный цикл без достаточной проверки происхождения и целостности.

Открыть карточку
A22 · Высокий

LoRA/adaptor tampering

Модель, данные, adapter или dependency попадают в жизненный цикл без достаточной проверки происхождения и целостности.

Открыть карточку
A23 · Высокий

Model merge/conversion compromise

Модель, данные, adapter или dependency попадают в жизненный цикл без достаточной проверки происхождения и целостности.

Открыть карточку
Открыть интерактивную карту угроз
Первоисточники

Международные источники и практики

Сначала мы объясняем практический смысл материала на русском. Ниже — первоисточники для проверки и детального изучения границ применимости.

OWASPLLM03:2025 Supply ChainЦепочка поставки моделей, данных и зависимостей.arXivModels Are Codes: Security Risks of Loading Untrusted ModelsИсследование рисков загрузки моделей и datasets.arXivSafePickle researchРиски unsafe deserialization в ML-моделях.