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

Андрей Жданухин, руководитель группы аналитики 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-инфраструктурой, чтобы обнаружить компрометацию не по факту появления вредоносного пакета, а по дальнейшим действиям злоумышленника внутри среды», — добавил Андрей Жданухин.