MLSecOps: защита ML-пайплайна от данных до прода

Понедельник, 9:15 утра. В Slack SOC-канале - алерт: модель кредитного скоринга за выходные одобрила 340 заявок с аномально высоким risk-скором. Postmortem показал: в четверг data-инженер закоммитил в DVC-репозиторий "обновлённый" датасет - 12 000 записей с подменёнными метками. CI/CD отработал штатно, модель переобучилась, A/B-тест показал приемлемые метрики на валидационной выборке, артефакт выехал в прод. SAST, SCA, container scan - всё зелёное. Классический DevSecOps-контур ничего не поймал, потому что отравление данных - не уязвимость в коде и не CVE в зависимостях. Это территория MLSecOps.

Почему DevSecOps для машинного обучения не работает из коробки​

В привычном DevSecOps мы защищаем код, зависимости и инфраструктуру. SAST ищет инъекции в исходниках, SCA проверяет CVE в пакетах, DAST тестирует HTTP-эндпоинты. Для обычного приложения - хватает. ML-пайплайн добавляет артефакты, которых в традиционном конвейере просто нет. Подробнее - в нашем обзоре безопасность llm приложений.

Данные - датасеты для обучения и валидации. Их нельзя просканировать Bandit или Trivy. Отравленный датасет не генерирует CVE и не появляется в advisory.

Модель - бинарный артефакт (файл весов), который определяет поведение системы. Подмена модели эквивалентна подмене бизнес-логики, но ни один инструмент из стандартного DevSecOps-стека её не видит.

Пайплайн обучения - DAG в Kubeflow, Airflow или аналоге. Компрометация одного шага (feature engineering, аугментация, валидация) каскадно ломает всю безопасность ИИ-систем ниже по потоку.

По данным Stanford AI Index 2025, порядка 78% опрошенных организаций используют ИИ хотя бы в одной бизнес-функции. При этом значительная часть организаций, внедряющих LLM, признаёт нехватку зрелости для защиты от AI-специфических угроз. Вот тут и зарыта проблема: темпы внедрения растут, а MLSecOps-практики - нет. Это конкретная точка входа для атакующих. По данным CrowdStrike Global Threat Report, среднее время латерального перемещения внутри сети продолжает сокращаться (от 62 до 18 минут в разных отчётах, зависит от года). Для ML-инфраструктуры, где security-контроли слабее основного контура, окно реагирования ещё уже.

MLSecOps (Machine Learning Security Operations) - применение security-практик к жизненному циклу безопасности ML, от проектирования и подготовки данных до инференса в продакшене. По сути - DevSecOps, адаптированный под специфику безопасной разработки ML: данные как код, модель как уязвимый артефакт, drift как аномалия.

Безопасность машинного обучения: карта TTPs через MITRE ATT&CK​

Чтобы SOC мог работать с ML-угрозами, их нужно описать на языке TTPs. Ниже - маппинг атак на ML-пайплайн к техникам MITRE ATT&CK.


Этот маппинг - не академическое упражнение. Часть ML-угроз (T1530, T1552.001, T1610) уже покрыта стандартными Sigma-пакетами. Отдельно стоит T1588.007 (Artificial Intelligence, Resource Development) - использование атакующим ML-инструментов для подготовки adversarial-атак. SOC-команде остаётся точечно дописать правила для ML-специфики: отравление данных, подмена модели, аномалии в inference API. Половина работы уже сделана - нужно добить оставшуюся.

Классификация OWASP LLM Top 10 (2025) тоже ложится сюда. LLM04 - Data and Model Poisoning описывает манипуляции с обучающими данными и embeddings. LLM01 - Prompt Injection покрывает атаки на инференс через crafted-инпуты, обходящие safety-контроли. LLM10 - Unbounded Consumption - DoS и model extraction через исчерпание ресурсов. Привязка к OWASP позволяет использовать эти идентификаторы при аудите безопасности ИИ-моделей и формировании отчётов для регулятора.

Защита данных ИИ-систем: отравление и insider threat​

Отравление данных - самая коварная атака на ML-систему. Последствия проявляются с задержкой в дни и недели. Модель переобучается, проходит валидацию (метрики могут даже улучшиться на чистой выборке) и уходит в прод. Детект происходит, когда бизнес уже понёс убытки. По сути - бомба замедленного действия, которую не видит ни один сканер.

Бизнес-логика атаки​

Зачем атакующему отравлять данные? Три типовых мотива:

1. Финансовая выгода - модель скоринга начинает одобрять мошеннические заявки. Классический fraud через скомпрометированный пайплайн.
2. Саботаж инсайдера - data scientist с доступом к DVC-репозиторию и MLflow незаметно подменяет датасет или корректирует гиперпараметры так, чтобы модель деградировала на определённом сегменте входных данных в проде.

Второй мотив - insider threat - практически не покрывается в русскоязычных материалах по MLSecOps. А зря. Data scientist с правами на запись в data-репозиторий и model registry - привилегированный пользователь с доступом к критичным артефактам. Для SOC это аналог DBA с правами на прод-базу: человек, действия которого требуют отдельного мониторинга и baseline. Понимание мотивов атакующего (внешний злоумышленник или инсайдер) - отправная точка для detection.

Что мониторить в SIEM​

Для detection отравления данных ML и инсайдерских атак нужен baseline нормального поведения безопасности конвейера данных:

• Объём коммитов в data-репозиторий - аномальный прирост записей или изменение распределения меток
• Время запуска пайплайна обучения - пересборка вне расписания или из нестандартной ветки
• Изменения гиперпараметров - diff между текущим и предыдущим экспериментом в MLflow
• Доступ к data storage - обращения к S3-бакету с датасетами из нехарактерных IP или сервисных аккаунтов (T1530)

Пример Sigma-правила для детектирования аномального коммита в data-репозиторий:
Правило сработает на push в репозиторий с датасетами от любого пользователя кроме CI-бота. Дальше аналитик проверяет diff: менялось ли распределение меток, размер файлов, формат данных. Если baseline зафиксирован (средний коммит - 500 записей, а пришло 12 000) - это повод для incident response.

Регуляторный контекст: ФЗ-152 и оборотные штрафы​

Если обучающие данные содержат персональные данные (ФЗ-152, ст. 3), оператор обязан обеспечить их конфиденциальность (ст. 7) и получить согласие субъектов на обработку с указанием конкретных целей (ст. 9). Использование ПДн для обучения модели - самостоятельная цель обработки, которая должна быть явно указана в согласии. Утечка или подмена датасета с ПДн - не только деградация модели, но и основание для оборотных штрафов. Повторная утечка грозит оборотным штрафом по установленной законом шкале - конкретные пороги зависят от объёма утечки и актуальной редакции КоАП. Штраф может составлять миллионы рублей, и это без учёта ущерба от скомпрометированной модели.

Защита ML-моделей от атак на supply chain​

Модель - артефакт с теми же supply-chain рисками, что и Docker-образ. Разница в зрелости: для контейнеров уже есть Notary/cosign и культура подписания, а для ML-моделей подписание артефактов пока внедрено далеко не везде.

По данным LegitSecurity, supply chain ML включает: package managers (PyPI, conda), pre-trained weights (Hugging Face), public datasets, open-source notebooks, CI/CD for AI models. Каждый компонент - вектор для T1195.001 (Compromise Software Dependencies) и T1195.002 (Compromise Software Supply Chain).

Практические меры контроля по шагам:

Шаг 1. Подписание моделей через cosign (Sigstore). Подписывайте файлы весов перед помещением в model registry. Если registry - MLflow, прикрутите подписание как post-hook в CI/CD. Команда cosign sign --key cosign.key model-v1.2.onnx занимает секунды, но блокирует подмену артефакта.

Шаг 2. AI Bill of Materials. Фиксируйте для каждой модели: DVC-хеш датасета, зависимости с lockfile, git commit пайплайна, хеш финального артефакта. Это аналог SBOM, но для ML. Без AI BOM расследование инцидента превращается в археологию - невозможно сказать, на каких данных обучалась модель полугодовой давности.

Шаг 3. Сканирование базовых образов. ML-пайплайны используют тяжёлые Docker-образы (nvidia/cuda, tensorflow/serving). Сканируйте их так же, как любые другие: trivy image --severity HIGH,CRITICAL <image> покажет CVE в зависимостях базового образа.

Шаг 4. OPA-политики для model registry. Ограничьте публикацию моделей через policy-as-code. Не полагайтесь на конвенции и устные договорённости - они не переживают ротацию команды.

Пример OPA-политики (Rego) для контроля деплоя модели:
Два контроля - подпись и ветка - отсекают большинство случайных и часть целенаправленных подмен артефакта. Политика встраивается через OPA/Gatekeeper в Kubernetes-кластер обучения и деплоя. MLOps безопасность на уровне policy-as-code воспроизводима, аудируема и не зависит от того, помнил ли ML-инженер про security при очередном push.

Безопасность искусственного интеллекта в продакшене: detection и мониторинг​

Model drift как IOC​

Data drift (изменение распределения входных данных) и concept drift (изменение связи между фичами и целевой переменной) - стандартные ML-метрики. Для SOC они интересны как potential IOC. Резкий drift может указывать на adversarial inputs (OWASP LLM01 - Prompt Injection) или на последствия ранее незамеченного data poisoning (OWASP LLM04).

Baseline строится на метриках за первые 2-4 недели стабильной работы модели. Подход согласуется с рекомендацией NIST CSF 2.0 (DE.AE-01): "A baseline of network operations and expected data flows for users and systems is established and managed""Устанавливаются и поддерживаются базовые показатели сетевых операций и ожидаемых потоков данных для пользователей и систем.". Аномалии, на которые нужно алертить:

• Скачок latency инференса на 30%+ без изменения нагрузки - возможный model extraction через массовые запросы (OWASP LLM10 - Unbounded Consumption). Защита моделей от инференс-атак начинается с rate limiting и мониторинга объёма запросов.
• Изменение распределения prediction confidence без изменения входного распределения - повод копнуть, особенно если совпадает с недавним переобучением.
• Аномальный рост запросов к inference API из одного источника - классический паттерн model extraction. Если кто-то шлёт тысячи запросов с минимальной вариацией инпутов - это не пользователь, это extraction.

Что агрегировать в SIEM​

Для корреляции ML-алертов с инфраструктурными событиями в SIEM нужно пробросить:

• Логи model serving (TensorFlow Serving, Triton, vLLM) - latency, error rate, prediction distribution
• Логи MLflow / model registry - кто, когда, какую версию зарегистрировал
• Логи Kubernetes (при ML на K8s) - события деплоя, изменения ConfigMap, обращения к secrets
• Аудит-логи data storage (CloudTrail для S3, GCS Audit Log)

Корреляционное правило для SIEM: алерт "аномальный drift" + "новая версия модели зарегистрирована вне расписания" + "push в data-репозиторий от нехарактерного пользователя" = высокоприоритетный инцидент. Три сигнала порознь - шум. Вместе - incident response: изоляция модели, откат к предыдущей подписанной версии, forensics по коммитам в data-репозиторий.

Чек-лист MLSecOps для SOC-команды​

Для команд с минимальным бюджетом: MITRE ATLAS - открытая база тактик и техник атак на ML (аналог ATT&CK для AI-систем), Microsoft Counterfit - open-source фреймворк для adversarial-тестирования моделей. Оба бесплатны и покрывают базовый уровень MLSecOps-оценки. OWASP DevSecOps Maturity Model (DSOMM) можно адаптировать для оценки зрелости MLSecOps-процессов: категории Build, Patch, Test, Culture применимы к ML-пайплайнам с минимальной адаптацией.


MLSecOps сейчас напоминает DevSecOps образца 2017-2018: все понимают "зачем", мало кто делает руками. По опыту аудитов ML-проектов, подписание моделей, мониторинг drift и проверка целостности датасетов в CI/CD чаще отсутствуют, чем присутствуют. При этом в тех же организациях SAST/SCA/DAST давно в пайплайне, container scan на каждый билд, SLA на патчинг - 48 часов. Разрыв не в бюджете и не в инструментах. Он в оргструктуре: data science живёт отдельно от AppSec, SOC не получает логи model serving, а CISO узнаёт про ML-модель в проде из отчёта аудитора.

Пока эти три функции не окажутся за одним тикет-бордом, MLSecOps останется слайдом в презентации, а не практикой в пайплайне. Самая частая отговорка: "data scientists не будут работать с security-тулингом". На практике сопротивление снижается, если дать cosign в один make sign и OPA-политику, которая не блокирует эксперименты в dev-ветке. Проблема не в людях - security-команда пытается перенести жёсткие gate из DevSecOps в ML без адаптации, ломая итеративный процесс экспериментов. Как только gate становится enabler - "ваш эксперимент защищён, а не заблокирован" - adoption взлетает. Если хотите сравнить подходы к мониторингу ML-пайплайнов в разных SIEM-стеках - тематический тред на codeby.net как раз для этого.