Киберэксперт Жданухин: "одна скомпрометированная библиотека может превратить цепочку разработки в канал утечки"

Как сообщает GBHackers, компрометация библиотеки LiteLLM вышла за рамки единичного инцидента с вредоносным пакетом на PyPI. Она показала, как взлом инструментов разработчика может превратить AI-инфраструктуру в канал для кражи учётных данных и облачных атак.

Андрей Жданухин, руководитель группы аналитики L1 GSOC компании "Газинформсервис", отметил, что в данном случае компрометация началась не непосредственно с AI-сервиса, а с цепочки поставок: атакующим удалось скомпрометировать компонент, использовавшийся в CI-среде LiteLLM, после чего через доверенный механизм зависимостей были опубликованы вредоносные версии пакета.

"Даже около 40 минут доступности таких релизов оказалось достаточно, чтобы создать потенциальный риск для разработчиков и автоматизированных пайплайнов: вредоносный код мог получить доступ к API-ключам, облачным учётным данным, токенам Kubernetes и другим секретам, которые находятся в окружении сборки. Этот случай особенно показателен для AI-проектов, где одна скомпрометированная библиотека способна превратить цепочку разработки и развёртывания моделей в канал дальнейшего проникновения в облачную и корпоративную инфраструктуру", — отметил эксперт компании "Газинформсервис".

Всего, по данным CloudSEK, потенциально затронуто более 2500 организаций и 434 000 CI/CD-пайплайнов.

Для защиты таких сред центр мониторинга и реагирования GSOC компании "Газинформсервис" рекомендует рассматривать AI-инфраструктуру как отдельную поверхность атаки и контролировать не только конечные модели, но и весь путь от репозитория и CI/CD до продуктивного inference-сервиса.

"Важную роль здесь играет проактивный поиск угроз: поиск аномального поведения сборочных агентов, неожиданных обращений к секретам, появления новых зависимостей, подозрительных сетевых соединений и нетипичных операций с Kubernetes или облачными ресурсами", — подчеркнул киберэксперт.

При этом, по его словам, организациям стоит внедрять практики DevSecOps и MlSecOps — фиксировать версии зависимостей, проверять происхождение пакетов, минимизировать права CI/CD-токенов и не допускать попадания секретов в общий контур сборки без необходимости.

"GSOC, в свою очередь, может обеспечить постоянный мониторинг событий из этого контура и корреляцию алертов между пользовательским сегментом, сетью, облачной и Kubernetes-инфраструктурой, чтобы обнаружить компрометацию не по факту появления вредоносного пакета, а по дальнейшим действиям злоумышленника внутри среды", — добавил Андрей Жданухин.