ML supply chain - реальная поверхность атаки. Введение

Насколько вообще защищены артефакты, на которых строится ML-пайплайн? На практике это не просто вопрос инженерной аккуратности, а полноценный вопрос supply chain security (кто создал артефакт, где он хранился, был ли он изменен и можно ли вообще ему доверять).

🏋️‍♀️ Мы привыкли обсуждать безопасность моделей через призму guardrails, фильтрации запросов и защиты inference-слоя. Но этого уже недостаточно.

Сегодня ML/AI supply chain — это уже не только про сами модели, но и про агентов, которым дали доступ к инструментам, API и внутренним системам. 🧐

Когда в ML-пайплайне нет проверки целостности, provenance и цифровых подписей для моделей и датасетов, организация получает классическую supply chain проблему - только уже на уровне AI. NIST (уже в 2024 году!) прямо рекомендует фиксировать integrity and provenance обучающих датасетов, защищать модели, веса и пайплайны от несанкционированного изменения, а также публиковать для AI-моделей криптографические хеши или цифровые подписи для проверки целостности релизов.

Почему это важно?
😭 Компрометированный артефакт может менять не только качество модели, но и поведение всей системы. OWASP относит Training Data Poisoning и Supply Chain Vulnerabilities к числу ключевых рисков для LLM/GenAI-приложений. Если атакующий подменяет датасет, модель, веса или промежуточный артефакт, это может привести к backdoor-поведению, смещению рекомендаций, ухудшению точности и скрытым отказам, которые не всегда видны на обычных метриках.

😭 Безопасная модель не равна безопасному агенту.
Как только система получает доступ к инструментам, файлам, API и внешним источникам данных, guardrails на уровне модели перестают быть достаточными. Microsoft отдельно описывает риски indirect prompt injection и tool poisoning в MCP/agent-сценариях. Проблема уже не только в том, что модель ответит мусорно, а в том, что она может вызвать не тот инструмент, дать утечь данным или выполнить нежелательное действие на основании недоверенного контента.

😭 Least privilege здесь обязателен, а не просто желателен.
NIST для AI-разработки отдельно рекомендует защищать модели, веса, пайплайны и данные, а также следовать принципу least privilege для доступа к AI-моделям и их элементам. В терминах Zero Trust это означает минимальные права на каждый запрос и отказ от неявного доверия к среде выполнения.

Что это значит технически
Уязвимость обычно выглядит так
😡 модель и/или датасет скачиваются из внешнего источника без проверки подписи;
😡 в пайплайне нет обязательной верификации хеша/attestation/provenance;
😡 артефакт автоматически подхватывается в training, evaluation или deployment;
😡 агент или сервис с широкими правами использует этот артефакт;
😡 компрометация переходит из ошибки в ML в полноценный секьюрити инцидент.

Ключевой момент в AI-среде заключается в том, что атака может долго маскироваться под странное поведение модели или косяки мл-инженера, хотя на самом деле это supply chain compromise.

Еще не все!
🦊

Проблема становится еще серьезнее, когда модель встроена в агентный контур. Один агент читает данные, второй вызывает API, третий обновляет внутренние системы. В такой архитектуре один компрометированный артефакт или poisoned context может стать точкой входа для каскадного сбоя во всей цепочке. Эффект домино!