Цепочка поставок (Supply Chain)

Описание

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

Эти внешние компоненты могут быть изменены злоумышленниками с помощью атак модификации (tampering) или отравления (poisoning).

Создание LLM — специализированная задача, которая часто опирается на сторонние модели. Распространение LLM с открытым доступом и новых методов дообучения, таких как LoRA (Low-Rank Adaptation, низкоранговая адаптация) и PEFT (Parameter-Efficient Fine-Tuning, параметрически эффективное дообучение), особенно на платформах вроде Hugging Face, порождает новые риски цепочки поставок. Наконец, появление LLM, работающих на устройствах (on-device LLM), расширяет поверхность атаки и риски цепочки поставок для приложений на базе LLM.

Часть рассматриваемых здесь рисков обсуждается также в разделе LLM04 «Отравление данных и модели» (Data and Model Poisoning). Данный раздел посвящен аспектам цепочки поставок. Простая модель угроз доступна по ссылке: https://github.com/jsotiro/ThreatModels/blob/main/LLM%20Threats-LLM%20Supply%20Chain.png.

Типовые примеры уязвимости

1. 1. Уязвимости традиционных сторонних пакетов. Например, устаревшие или выведенные из поддержки компоненты, которые злоумышленники могут эксплуатировать для компрометации LLM-приложений. Это аналогично категории A06:2021 – Vulnerable and Outdated Components (уязвимые и устаревшие компоненты), но с повышенными рисками, когда компоненты используются при разработке или дообучении модели (см.: A06:2021 – Vulnerable and Outdated Components, https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/).
2. 2. Лицензионные риски. Разработка AI часто связана с множеством лицензий на ПО и наборы данных, что создает риски при ненадлежащем управлении ими. Различные открытые и проприетарные лицензии налагают разные юридические требования. Лицензии на наборы данных могут ограничивать их использование, распространение или коммерциализацию.
3. 3. Устаревшие или выведенные из поддержки модели. Использование устаревших или выведенных из поддержки моделей, которые больше не сопровождаются, приводит к проблемам безопасности.
4. 4. Уязвимая предобученная модель. Модели представляют собой двоичные «черные ящики», и, в отличие от открытого кода, статический анализ дает мало или вовсе не дает гарантий безопасности. Уязвимые предобученные модели могут содержать скрытые искажения (biases), бэкдоры или иные вредоносные функции, не выявленные в ходе проверок безопасности в репозиториях моделей. Уязвимые модели могут быть созданы как с помощью отравленных наборов данных, так и путем прямой модификации модели с использованием таких методов, как ROME, известного также как «лоботомизация» (lobotomisation).
5. 5. Слабое подтверждение происхождения модели (provenance). В настоящее время для опубликованных моделей отсутствуют надежные гарантии происхождения. Карточки моделей (Model Cards) и сопутствующая документация содержат сведения о модели, и пользователи на них полагаются, однако они не дают гарантий относительно происхождения модели. Злоумышленник может скомпрометировать учетную запись поставщика в репозитории моделей или создать похожую и в сочетании с методами социальной инженерии скомпрометировать цепочку поставок LLM-приложения.
6. 6. Уязвимые LoRA-адаптеры. LoRA — популярный метод дообучения, повышающий модульность за счет возможности подключать предобученные слои к существующей LLM. Метод повышает эффективность, но создает новые риски: вредоносный LoRA-адаптер может нарушить целостность и безопасность предобученной базовой модели. Это может происходить как в средах совместного слияния моделей (model merge), так и через эксплуатацию поддержки LoRA в популярных платформах развертывания инференса, таких как vLLM и OpenLLM, где адаптеры можно загружать и применять к уже развернутой модели.
7. 7. Эксплуатация процессов совместной разработки. Сервисы совместного слияния моделей и обработки моделей (например, конвертации), размещенные в общих средах, могут быть использованы для внедрения уязвимостей в общие модели. Слияние моделей очень популярно на Hugging Face — модели, полученные слиянием, возглавляют рейтинг OpenLLM leaderboard, — и этим можно воспользоваться для обхода проверок. Аналогичным образом было доказано, что такие сервисы, как бот конвертации, уязвимы для манипуляций и могут внедрять в модели вредоносный код.
8. 8. Уязвимости цепочки поставок LLM на устройствах. LLM на устройствах расширяют поверхность атаки на цепочку поставок за счет скомпрометированных производственных процессов и эксплуатации уязвимостей ОС или прошивки устройства для компрометации моделей. Злоумышленники могут провести обратную разработку (reverse engineering) приложений и переупаковать их с модифицированными моделями.
9. 9. Неясные условия использования и политики конфиденциальности данных. Неясные условия использования (T&Cs) и политики конфиденциальности операторов моделей приводят к тому, что конфиденциальные данные приложения используются для обучения модели и впоследствии раскрываются. Это может касаться и рисков, связанных с использованием поставщиком модели материалов, защищенных авторским правом.

Меры предотвращения и смягчения

1. 1. Тщательно проверяйте источники данных и поставщиков, включая их условия использования и политики конфиденциальности, и используйте только доверенных поставщиков. Регулярно анализируйте и проверяйте обеспечение безопасности и контроль доступа у поставщиков, убеждаясь в отсутствии изменений в их уровне защищенности или условиях использования.
2. 2. Изучите и применяйте меры, описанные в категории OWASP Top Ten A06:2021 – Vulnerable and Outdated Components. Сюда входят сканирование уязвимостей, управление компонентами и установка исправлений. Для сред разработки с доступом к конфиденциальным данным применяйте эти меры и в них (см.: A06:2021 – Vulnerable and Outdated Components, https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/).
3. 3. При выборе сторонней модели проводите всестороннее тестирование методами AI Red Teaming и оценку модели. Decoding Trust — пример эталонного теста (бенчмарка) надежного AI для LLM, однако модели могут быть дообучены так, чтобы обходить опубликованные бенчмарки. Используйте обширное AI Red Teaming для оценки модели, особенно в тех сценариях, в которых вы планируете ее применять.
4. 4. Поддерживайте актуальный реестр компонентов с помощью спецификации программного обеспечения (Software Bill of Materials, SBOM), чтобы иметь актуальный, точный и подписанный перечень, предотвращающий модификацию развернутых пакетов. SBOM можно использовать для быстрого обнаружения новых уязвимостей нулевого дня и оповещения о них. AI BOM и ML SBOM — развивающееся направление; начните оценку вариантов с OWASP CycloneDX.
5. 5. Для снижения лицензионных рисков в AI составьте реестр всех задействованных типов лицензий с помощью BOM и регулярно проводите аудит всего ПО, инструментов и наборов данных, обеспечивая соответствие требованиям и прозрачность через BOM. Используйте средства автоматизированного управления лицензиями для мониторинга в реальном времени и обучайте команды моделям лицензирования. Ведите подробную документацию по лицензиям в BOM и применяйте такие инструменты, как Dyana (https://github.com/dreadnode/dyana), для динамического анализа стороннего ПО.
6. 6. Используйте модели только из проверяемых источников и применяйте сторонние проверки целостности моделей с использованием подписей и хешей файлов, чтобы компенсировать отсутствие надежного подтверждения происхождения моделей. Аналогично используйте подпись кода для кода, поставляемого извне.
7. 7. Внедрите строгий мониторинг и аудит сред совместной разработки моделей, чтобы предотвращать и оперативно выявлять любые злоупотребления. Пример автоматизированных скриптов для этой цели — HuggingFace SF_Convertbot Scanner (см.: https://gist.github.com/rossja/d84a93e5c6b8dd2d4a538aa010b29163).
8. 8. Обнаружение аномалий и тесты на устойчивость к состязательным атакам (adversarial robustness) для поставляемых моделей и данных помогают выявлять модификацию и отравление, как описано в разделе LLM04 «Отравление данных и модели». В идеале это должно быть частью конвейеров MLOps и LLM, однако эти методы только развиваются, и их может быть проще реализовать в рамках учений red team.
9. 9. Внедрите политику установки исправлений для устранения уязвимых или устаревших компонентов. Убедитесь, что приложение использует поддерживаемые версии API и базовой модели.
10. 10. Шифруйте модели, развернутые на периферии (AI edge), с проверкой целостности и используйте API аттестации поставщика, чтобы предотвращать использование модифицированных приложений и моделей и завершать работу приложений с нераспознанной прошивкой.

Примеры сценариев атак

1. Сценарий 1. Уязвимая библиотека Python. Атакующий эксплуатирует уязвимую библиотеку Python для компрометации LLM-приложения. Именно это произошло при первой утечке данных OpenAI. Атаки на реестр пакетов PyPi вынудили разработчиков моделей загрузить скомпрометированную зависимость PyTorch с вредоносным ПО в среду разработки моделей. Более изощренный пример такого типа атак — атака ShadowRay на фреймворк Ray AI, используемый многими поставщиками для управления AI-инфраструктурой. Считается, что в ходе этой атаки в реальных условиях были проэксплуатированы пять уязвимостей, затронувших множество серверов.
2. Сценарий 2. Прямая модификация. Прямая модификация и публикация модели с целью распространения дезинформации. Это реальная атака: PoisonGPT обошел защитные механизмы Hugging Face за счет непосредственного изменения параметров модели.
3. Сценарий 3. Дообучение популярной модели. Атакующий дообучает популярную модель с открытым доступом, чтобы удалить ключевые защитные функции и добиться высоких показателей в конкретной области (страхование). Модель дообучена так, чтобы получать высокие оценки в бенчмарках безопасности, но содержит узконаправленные триггеры. Атакующий размещает ее на Hugging Face, рассчитывая, что жертвы начнут ее использовать, доверяя результатам бенчмарков.
4. Сценарий 4. Предобученные модели. LLM-система развертывает предобученные модели из широко используемого репозитория без тщательной проверки. Скомпрометированная модель вносит вредоносный код, вызывая в определенных контекстах предвзятые результаты и приводя к вредным или искаженным последствиям.
5. Сценарий 5. Скомпрометированный сторонний поставщик. Скомпрометированный сторонний поставщик предоставляет уязвимый LoRA-адаптер, который объединяется с LLM с помощью слияния моделей на Hugging Face.
6. Сценарий 6. Проникновение к поставщику. Атакующий проникает к стороннему поставщику и компрометирует производство LoRA-адаптера (Low-Rank Adaptation), предназначенного для интеграции с LLM на устройстве, развернутой с помощью таких фреймворков, как vLLM или OpenLLM. Скомпрометированный LoRA-адаптер незаметно изменен: в него добавлены скрытые уязвимости и вредоносный код. После слияния адаптера с LLM у атакующего появляется скрытая точка входа в систему. Вредоносный код может активироваться во время работы модели, позволяя атакующему манипулировать выводом LLM.
7. Сценарий 7. Атаки CloudBorne и CloudJacking. Эти атаки направлены на облачные инфраструктуры и используют общие ресурсы и уязвимости уровней виртуализации. CloudBorne предполагает эксплуатацию уязвимостей прошивки в общих облачных средах с компрометацией физических серверов, на которых размещены виртуальные экземпляры. CloudJacking означает злонамеренный захват контроля над облачными экземплярами или их неправомерное использование, что может привести к несанкционированному доступу к критически важным платформам развертывания LLM. Обе атаки представляют значительный риск для цепочек поставок, зависящих от облачных ML-моделей, поскольку скомпрометированные среды могут раскрыть конфиденциальные данные или способствовать дальнейшим атакам.
8. Сценарий 8. LeftOvers (CVE-2023-4969). Эксплуатация LeftOvers — использование утечки локальной памяти GPU для восстановления конфиденциальных данных. Атакующий может применить эту атаку для эксфильтрации конфиденциальных данных с production-серверов, рабочих станций разработчиков или ноутбуков.
9. Сценарий 9. WizardLM. После удаления WizardLM атакующий пользуется интересом к этой модели и публикует поддельную версию с тем же названием, но содержащую вредоносное ПО и бэкдоры.
10. Сценарий 10. Сервис слияния моделей или конвертации форматов. Атакующий проводит атаку через сервис слияния моделей или конвертации форматов, чтобы скомпрометировать общедоступную модель и внедрить в нее вредоносное ПО. Это реальная атака, опубликованная компанией HiddenLayer.
11. Сценарий 11. Обратная разработка мобильного приложения. Атакующий проводит обратную разработку мобильного приложения и заменяет модель модифицированной версией, которая направляет пользователя на мошеннические сайты. С помощью методов социальной инженерии пользователей побуждают загружать приложение напрямую. Это «реальная атака на предиктивный AI» (real attack on predictive AI), затронувшая 116 приложений в Google Play, в том числе популярные приложения, критичные для безопасности: для распознавания наличных денег, родительского контроля, аутентификации по лицу и финансовых услуг (см.: https://arxiv.org/abs/2006.08131).
12. Сценарий 12. Отравление набора данных. Атакующий отравляет общедоступные наборы данных, чтобы создать бэкдор при дообучении моделей. Бэкдор незаметно отдает предпочтение определенным компаниям на разных рынках.
13. Сценарий 13. Условия использования и политика конфиденциальности. Оператор LLM изменяет условия использования и политику конфиденциальности так, что для исключения данных приложения из обучения модели требуется явный отказ (opt-out), что приводит к запоминанию моделью конфиденциальных данных.

Связанные фреймворки и таксономии

• MITRE ATLAS: ML Supply Chain Compromise (компрометация цепочки поставок ML), https://atlas.mitre.org/techniques/AML.T0010