🔗 Supply-chain риски LLM-приложений (LLM03): как защитить цепочку поставок модели от отравленных компонентов

Целевая аудитория: Команды, которые собирают, дообучают и развёртывают LLM из сторонних компонентов — предобученных моделей, датасетов, LoRA/PEFT-адаптеров, PyPI-пакетов, плагинов и MCP-серверов, — и отвечают за то, чтобы скомпрометированный «кирпич» цепочки не превратил всё приложение в канал атаки.

Supply-chain риски LLM-приложений (supply chain) — это уязвимости, которые приходят не из вашего кода, а из сети сторонних компонентов, на которых ваша модель строится, обучается, дообучается, разворачивается и работает: чужие веса, корпуса данных, адаптеры, библиотеки, инструменты. Коварство класса в том, что скомпрометированный компонент ведёт себя штатно — проходит ваши тесты, отвечает корректно — ровно до момента, когда срабатывает заложенный триггер. Этот риск зафиксирован в OWASP Top 10 для LLM 2025 как LLM03:2025 Supply Chain. На этой странице мы разбираем реальные векторы компрометации цепочки поставок и честно показываем, что здесь делает — и чего намеренно НЕ делает — SYNTREX — защитный слой платформы Spectorn (набор движков обнаружения и блокировки, который работает в составе Spectorn и разворачивается standalone на внутреннем контуре заказчика).

Сразу важная оговорка, без которой вся страница читается неверно: безопасность цепочки поставок — это в первую очередь организационная и DevSecOps-дисциплина (верификация происхождения, проверка подписей и хешей, SBOM/ML-BOM, пиннинг версий, ветинг пакетов и моделей ДО установки). Движки детекции рантайма её не заменяют. Защита SYNTREX дополняет эту дисциплину там, где она бессильна: она контролирует поведение уже установленного компонента во время работы (egress, спящие нагрузки, радиус поражения), но не проверяет легитимность артефакта в момент его загрузки.

Часть серии: OWASP LLM Top 10 · MCP-серверы · Безопасность RAG-систем · Утечка данных.

Почему компонент опасен ещё до первой строки вашего кода

Современное LLM-приложение — это сборка из чужих частей, каждая из которых может быть точкой компрометации:

Предобученная модель — чужие веса с Hugging Face или из приватного реестра. Никаких сильных гарантий происхождения у публичных моделей сегодня нет: Model Card даёт описание, но не доказательство, что веса не были изменены после публикации.
Датасет — корпус для обучения или дообучения, в который мог попасть отравленный контент.
LoRA/PEFT-адаптер — небольшой «довесок» к базовой модели, меняющий её поведение; именно компактность делает его удобным носителем скрытой модификации.
PyPI-пакет — библиотека и её транзитивные зависимости в обучающем или инференс-пайплайне.
Плагин / MCP-сервер — внешний инструмент, который агент вызывает в рантайме (см. безопасность MCP-серверов).

Объединяет их одно свойство, которое и делает класс таким опасным: компонент ведёт себя нормально до срабатывания триггера. Бэкдор в весах, sleeper-нагрузка в адаптере, вредоносная транзитивная зависимость в пакете — всё это спит, пока не наступит заданное условие (конкретная фраза-ключ, дата, домен, тип запроса). Поэтому функциональное тестирование «модель отвечает правильно» ничего не гарантирует: вы проверяете поведение в отсутствие триггера. Реальная защита делится на два контура — проверять артефакт до установки (происхождение, подпись, хеш — DevSecOps) и сдерживать поведение компонента в рантайме (это зона движков SYNTREX).

🛑 Векторы компрометации цепочки и как SYNTREX их закрывает

1. Typosquatting на PyPI: пакет крадёт креды и подменяет checkpoint

Риск: В обучающий пайплайн через опечаточное имя затягивается вредоносный PyPI-пакет (или вредоносная транзитивная зависимость легитимного с виду пакета). На стадии сборки он делает две вещи: эксфильтрует API-токены и облачные учётные данные из окружения CI и модифицирует checkpoint модели перед его выгрузкой в реестр. В итоге заражены сразу и секреты организации, и сама модель, которую вы потом раздаёте в прод.

OWASP LLM03:2025 Supply Chain · MITRE ATLAS AML.T0048 (Compromise ML Software Dependencies), AML.T0024 (Exfiltration via ML Inference API).

Защита SYNTREX:

Движки/компоненты: secret_scanner, exfiltration, Decision Logger.
secret_scanner — всегда включённый инвариант Step-0: токены, ключи, пароли и connection strings маскируются в полезной нагрузке до того, как покинут периметр, что снижает ценность кражи кредов скомпрометированным пакетом на рантайм-рубеже.
exfiltration распознаёт аномальную выгрузку данных в исходящем потоке; Decision Logger фиксирует неизменяемый след (SHA-256/HMAC) для последующего разбора инцидента.

Что SYNTREX честно НЕ заменяет: ветинг пакетов и их транзитивных зависимостей ДО установки — это DevSecOps. Пиннинг версий, проверка хешей в lock-файле, изоляция CI-секретов, сканирование зависимостей и SBOM — всё это организационные контроли уровня сборки. SYNTREX не является сканером зависимостей и не проверяет легитимность пакета при pip install; он работает с поведением уже работающего компонента, а не с артефактом на полке.

2. Отравленный LoRA-адаптер с Hugging Face (имя автора в один символ)

Риск: Сообществу предлагается «дообучение под финансовый домен» — LoRA-адаптер, выложенный под именем пользователя, отличающимся от настоящего автора на один символ. Внутри — изменённый вес, который аккуратно искажает поведение: например, систематически занижает оценки риска. Функционально адаптер выглядит рабочим, метрики на общих примерах не проседают — смещение проявляется только на тех входах, ради которых атака и затевалась.

OWASP LLM03:2025 Supply Chain · MITRE ATLAS AML.T0010 (ML Supply Chain Compromise), AML.T0018 (Backdoor ML Model).

Защита SYNTREX:

Движки/компоненты: model_containment, dormant_payload.
model_containment удерживает компонент (модель + адаптер) в рамках заявленного поведенческого профиля и поднимает алерт, когда выход систематически выходит за эти границы в рантайме.
dormant_payload нацелен на выявление триггерных/спящих нагрузок, активирующихся по условию, — это рантайм-сигнал, а не верификация артефакта.

Что SYNTREX честно НЕ заменяет: проверку происхождения и подписи адаптера ДО развёртывания. Сегодня у публичных адаптеров и моделей нет сильных гарантий происхождения — Model Card информативна, но не доказывает источник. Сверка автора, хеша весов и подписи, ветинг адаптера в карантинной среде — это процедуры закупки и DevSecOps, а не функция движка. SYNTREX страхует вас в рантайме, но не подтверждает, что вы скачали именно то, что думали.

3. Прямая правка весов: PoisonGPT / ROME-бэкдор

Риск: Атакующий берёт легитимную модель и напрямую редактирует её параметры, внедряя бэкдор хирургически — методом ROME, точечно меняя факты или поведение («лоботомизация»). Именно так был устроен реальный PoisonGPT: отравленная модель прошла механизмы Hugging Face и распространялась как обычная, выдавая ложь по заданному триггеру и оставаясь корректной во всём остальном. Обнаружить такое функциональным тестированием почти невозможно — модель «здорова» везде, кроме узкой триггерной зоны.

OWASP LLM03:2025 Supply Chain · MITRE ATLAS AML.T0018 (Backdoor ML Model), AML.T0010 (ML Supply Chain Compromise).

Защита SYNTREX:

Движки/компоненты: dormant_payload, model_containment, SOC Correlation Engine.
dormant_payload нацелен на момент срабатывания спящей нагрузки в рантайме — когда «здоровая» модель внезапно выдаёт триггерное поведение; model_containment фиксирует выход за заявленные поведенческие границы.
Аномальная активация коррелируется в SOC, а Decision Logger сохраняет неизменяемый след события для расследования.

Что SYNTREX честно НЕ заменяет: верификацию хеша и подписи модели ДО загрузки. Прямую правку весов на стороне поставщика ловит сверка контрольной суммы с доверенным эталоном и подписанные артефакты — это процедура DevSecOps/procurement. SYNTREX не проверяет целостность весов при установке и не является верификатором подписей; он реагирует на аномальное поведение скомпрометированной модели уже в работе.

4. Скрытые инструкции внутри Model Card, датасета или подтянутого контента

Риск: Компонент несёт не вредоносный код, а вредоносный текст: инструкция, спрятанная в Model Card, в README репозитория модели, в поле описания датасета или в контенте, который компонент подтягивает в контекст. Модель читает этот текст как доверенное указание и исполняет его — классическая косвенная инъекция, но прибывшая по каналу цепочки поставок, а не от пользователя.

OWASP LLM03:2025 Supply Chain, LLM01:2025 Prompt Injection · MITRE ATLAS AML.T0048 (Compromise ML Software Dependencies).

Защита SYNTREX:

Движки/компоненты: injection, Decision Logger.
injection инспектирует метаданные и подтягиваемый контент компонента — Model Card, описания, датасетные поля — на встроенные инструкции, попытки переопределить системные указания и скрытые/невидимые символы, прежде чем этот текст попадёт в контекст модели.
Decision Logger фиксирует, какой именно фрагмент был перехвачен, давая доказуемый след для разбора.

5. Типосквоттинг MCP-сервера или npm-плагина

Риск: Атакующий публикует поддельный пакет, мимикрирующий под легитимный MCP-сервер или npm-плагин (опечаточное имя в реестре), с вредоносной нагрузкой — например, тихо пересылающей копии корпоративных данных наружу. Поддельный MCP-сервер — это в точности компрометация цепочки поставок, только носитель здесь рантайм-инструмент агента (подробный разбор — в безопасности MCP-серверов). Проверяемость экосистемы низкая: лишь малая доля публичных серверов несёт знак верификации.

OWASP LLM03:2025 Supply Chain · MITRE ATLAS AML.T0048 (Compromise ML Software Dependencies), AML.T0024 (Exfiltration via ML Inference API).

Защита SYNTREX:

Движки/компоненты: output_scanner, exfiltration, lethal_trifecta.
Развёрнутый перед сторонним компонентом как gateway/прокси SYNTREX инспектирует содержимое вывода и ответа: exfiltration распознаёт в этом содержимом скрытую пересылку данных (например, массовый BCC-поток), lethal_trifecta поднимает критический алерт при совпадении в контенте признаков «доступ к данным + недоверенный ввод + канал наружу», а output_scanner блокирует или редактирует нарушающий вывод. Это снижает радиус поражения скомпрометированного или подменённого компонента на уровне рантайма через инспекцию контента, а не сетевой egress-фильтр.
secret_scanner страхует от увода токенов через параметры вызова инструмента.

Что SYNTREX честно НЕ заменяет: проверку происхождения, подписи и репутации сервера/пакета ДО подключения — это задача supply-chain инструментов и процессов закупки ПО. SYNTREX контролирует поведение компонента в рантайме (инспектирует содержимое вывода и ответа, ловит спящие нагрузки, сужает радиус поражения), а не легитимность артефакта при установке.

6. Отложенная нагрузка в дообученной модели (sleeper agent)

Риск: Модель, прошедшая дообучение на скомпрометированном корпусе или адаптере, несёт «sleeper agent»: вредоносное поведение, дремлющее до конкретного триггера (Phantom/CorruptRAG-сценарии). До активации она неотличима от чистой — ровно поэтому supply-chain пересекается с отравлением данных (LLM04 Data and Model Poisoning и безопасность RAG). Опасность в том, что триггер выбирает атакующий, и он редко совпадает с вашим тест-сетом.

OWASP LLM03:2025 Supply Chain, LLM04:2025 Data and Model Poisoning · MITRE ATLAS AML.T0018 (Backdoor ML Model), AML.T0010 (ML Supply Chain Compromise).

Защита SYNTREX:

Движки/компоненты: dormant_payload, model_containment, injection.
dormant_payload — основной рантайм-сигнал по этому классу: он нацелен на момент срабатывания спящей нагрузки, когда модель отклоняется от штатного поведения по триггеру; model_containment фиксирует выход за заявленный профиль; injection ловит скрытые инструкции в подтягиваемом контенте, если триггер приходит через данные.

Что SYNTREX честно НЕ заменяет: фундаментально проблема «бэкдор зашит в веса при обучении» решается на стороне обучения и поставки (контроль происхождения корпуса и адаптера, воспроизводимая сборка, подписанные артефакты). dormant_payload помогает частично и в рантайме — выявляя активацию, а не гарантируя отсутствие бэкдора. Это не верификатор чистоты модели.

🛠️ Рекомендуемая конфигурация

Профиль защиты цепочки поставок — приоритет на рантайм-сдерживании поведения компонента: спящие нагрузки, удержание модели в границах, инспекция содержимого вывода/ответа и ограничение радиуса поражения. Этот профиль дополняет, а не подменяет процессы SBOM/ML-BOM, верификации подписей и пиннинга версий на стороне сборки:

YAML

# syntrex.yaml — профиль рантайм-защиты цепочки поставок (LLM03)
# ВАЖНО: это рантайм-контур. Верификация происхождения, подписей, хешей,
# SBOM/ML-BOM и пиннинг версий выполняются отдельно, средствами DevSecOps.
version: "1.0"
mode: supply_chain_runtime

engines:
  dormant_payload:
    action: alert                  # срабатывание спящей/триггерной нагрузки (Phantom/CorruptRAG)
    confidence_threshold: 0.80
  model_containment:
    action: block                  # удержание компонента в заявленных поведенческих границах
  injection:
    action: block                  # скрытые инструкции в Model Card / датасете / подтянутом контенте
    inspect_tool_descriptions: true
    inspect_tool_output: true
    confidence_threshold: 0.80
  exfiltration:
    action: block                  # скрытая выгрузка данных скомпрометированным компонентом
    confidence_threshold: 0.90
  lethal_trifecta:
    action: block                  # доступ к данным + недоверенный ввод + канал наружу
  secret_scanner: always_on        # Step-0 инвариант: токены/ключи не уходят через параметры компонента
  provenance_reduction:
    action: alert                  # попытка убрать атрибуцию источника перед выводом

shield:
  dmz: true                        # Shield DMZ перед сторонним компонентом, инспекция содержимого вывода и ответа

audit:
  decision_logger: true            # неизменяемая цепочка (SHA-256/HMAC) для разбора инцидентов

🚨 Правила корреляции (SOC)

Компрометация компонента видна либо как срабатывание спящей нагрузки с последующим аномальным действием, либо как «новый/обновлённый сторонний компонент → доступ к секретам или всплеск исходящего трафика»:

JSON

{
  "name": "SUPPLY_CHAIN_DORMANT_PAYLOAD_TRIGGER",
  "description": "Срабатывание спящей/триггерной нагрузки в компоненте, за которым следует аномальное действие или попытка вывода наружу",
  "condition": "sequence(dormant_payload[confidence>0.7], exfiltration[match=true] OR lethal_trifecta[confidence>0.7], 20s)",
  "severity": "CRITICAL",
  "playbook": "quarantine_component_and_alert_soc"
}

JSON

{
  "name": "SUPPLY_CHAIN_NEW_COMPONENT_CRED_ACCESS",
  "description": "Новый или обновлённый сторонний компонент обращается к учётным данным или даёт всплеск исходящего трафика вскоре после введения",
  "condition": "sequence(component[event='new_or_updated'], secret_scanner[access=true] OR exfiltration[outbound_spike=true], 60s)",
  "severity": "HIGH",
  "playbook": "isolate_component_and_review_provenance"
}

❓ Частые вопросы (FAQ)

Что такое supply-chain риски LLM (LLM03) простыми словами? Это уязвимости, которые приходят из сторонних компонентов, на которых строится ваша модель: чужих весов, датасетов, LoRA-адаптеров, PyPI-пакетов, плагинов и MCP-серверов. Скомпрометированный компонент ведёт себя нормально и проходит тесты вплоть до срабатывания заложенного триггера. OWASP относит этот класс к LLM03:2025 Supply Chain. Защита делится на два контура: проверка артефакта до установки (происхождение, подпись, хеш — DevSecOps) и сдерживание его поведения в рантайме (egress, спящие нагрузки, радиус поражения — здесь работает SYNTREX).

Как проверить безопасность модели с Hugging Face? Честно: надёжной гарантии происхождения у публичных моделей сегодня нет — Model Card описывает модель, но не доказывает, что веса не подменены. Минимальная гигиена до развёртывания: сверять автора (typosquatting в имени отличается на символ), проверять хеш и подпись весов против доверенного эталона, прогонять модель в карантинной среде, не давать ей сразу доступ к секретам и внешним каналам. Это процедуры DevSecOps и закупки. В рантайме SYNTREX страхует вас: dormant_payload нацелен на срабатывание спящих нагрузок, model_containment удерживает модель в заявленных границах, но он не верифицирует, что вы скачали именно оригинал.

Что такое отравление LoRA-адаптера? LoRA/PEFT-адаптер — компактный «довесок» к базовой модели, меняющий её поведение. Отравленный адаптер (например, выложенный под именем автора в один символ от настоящего) содержит изменённый вес, который аккуратно искажает выводы — скажем, занижает оценки риска — и проявляется только на целевых входах, не проседая на общих метриках. До деплоя его надо проверять по происхождению и подписи (DevSecOps); в рантайме model_containment ловит систематический выход за границы поведения, а dormant_payload — триггерную активацию.

Может ли SYNTREX сканировать зависимости или строить SBOM? Нет. Прямого сканера зависимостей в SYNTREX нет, и он не строит SBOM/ML-BOM, не пиннит версии и не верифицирует подписи и хеши артефактов. Это зона процессов DevSecOps и закупки ПО. SYNTREX — рантайм-слой: он контролирует поведение уже установленного компонента (инспектирует содержимое вывода и ответа через output_scanner, ловит спящие нагрузки dormant_payload, сужает радиус поражения через lethal_trifecta и exfiltration), но не проверяет легитимность пакета или модели в момент установки. Эти два контура дополняют друг друга и не заменяют один другой.

Как ограничить ущерб от скомпрометированного компонента? Сократить радиус поражения в рантайме. Принцип наименьших привилегий: не давайте стороннему компоненту одновременно доступ к приватным данным, контакт с недоверенным вводом и канал наружу — это «летальная тройка», и lethal_trifecta поднимает критический алерт при их совпадении. Разверните перед компонентом Shield DMZ, чтобы инспектировать содержимое его вывода и ответа; exfiltration распознаёт скрытую выгрузку в этом содержимом, secret_scanner маскирует токены в ответе, а Decision Logger сохраняет неизменяемый след для разбора. Это не отменяет ветинг до установки, но ограничивает то, что успеет сделать уже проникший компонент.

Что такое PoisonGPT? PoisonGPT — реальная демонстрация (Mithril Security) того, как отравленная модель распространяется через публичный хаб. Атакующие напрямую отредактировали параметры легитимной модели методом ROME («лоботомизация»), внедрив бэкдор: модель выдавала ложь по заданному триггеру и оставалась корректной во всём остальном, пройдя при этом механизмы Hugging Face. Функциональным тестом такое почти не поймать — модель «здорова» везде, кроме узкой триггерной зоны. До загрузки это закрывается сверкой хеша и подписи с доверенным эталоном; в рантайме dormant_payload нацелен на момент срабатывания, а model_containment фиксирует выход за поведенческие границы.

Чем supply-chain риск MCP-сервера отличается от обычного пакета? Природа та же — компрометация стороннего компонента, — но носитель и канал разные. Обычный пакет вредит в основном на стадии сборки/инференса (вредоносная зависимость крадёт креды, правит checkpoint). Поддельный MCP-сервер действует в рантайме как инструмент агента: он декларирует инструменты (которые модель читает как доверенные), возвращает вывод из внешнего мира и держит токены — поэтому к нему добавляются tool poisoning, индиректная инъекция и кража токенов. Поэтому для MCP важнее рантайм-сдерживание (Shield DMZ, injection на описаниях и выводе инструментов, lethal_trifecta); подробный разбор — в безопасности MCP-серверов. В обоих случаях верификация происхождения до подключения остаётся задачей DevSecOps.

📚 Источники

OWASP LLM03:2025 — Supply Chain — первоисточник по классу рисков цепочки поставок LLM.
OWASP Top 10 для LLM-приложений (2025) — каталог рисков LLM01–LLM10.
MITRE ATLAS — AML.T0010 (ML Supply Chain Compromise), AML.T0048 (Compromise ML Software Dependencies), AML.T0018 (Backdoor ML Model), AML.T0024 (Exfiltration via ML Inference API).
Mithril Security — PoisonGPT: как мы спрятали лоботомированную LLM на Hugging Face — эталонный реальный кейс прямой правки весов.
NIST AI Risk Management Framework (AI RMF 1.0) — управленческий каркас рисков сторонних компонентов AI-систем.
NIST SSDF / Software Bill of Materials (SBOM) — справочник по практикам безопасной разработки и составу ПО для процессов DevSecOps.

Связанные руководства: OWASP LLM Top 10 · MCP-серверы · Утечка данных · Избыточные полномочия AI-агентов · Безопасность RAG-систем · Утечка системного промпта