sber
Не сто резюме, а сто друзей: почему рекомендации снова стали валютой рынка труда
РМИАЦ Бурятии запустил отказоустойчивый кластер на базе РЕД ВИРТ
Свыше тысячи школ Уральского ФО выбрали ОС Astra Linux для цифровизации образования
Иван Хрулев, «Группа Астра»: «Astra Automation – уникальная на российском рынке платформа по спектру возможностей»
КПД ИИ-контура: новая метрика для CIO
ЦБ
°
четверг, 13 августа 2026

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

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

Свежее по теме