Проверили безопасность — и пропустили взлом: как аудит Delve оказался под вопросом
Delve провела аудит безопасности LiteLLM до атаки с вредоносным кодом
Generated by DALL·E
История вокруг популярной библиотеки LiteLLM неожиданно затронула не только разработчиков, но и рынок compliance-сервисов. После масштабной атаки на цепочку поставок выяснилось: безопасность проекта ранее проверяла компания Delve — и теперь её роль вызывает всё больше вопросов.
Что произошло с LiteLLM
В конце марта 2026 года две версии Python-библиотеки LiteLLM (1.82.7 и 1.82.8) оказались заражены вредоносным кодом. Пакеты были опубликованы злоумышленниками, получившими доступ к аккаунту разработчика.
LiteLLM — это широко используемый инструмент, позволяющий работать сразу с несколькими AI-моделями через единый интерфейс. Популярность проекта огромна: десятки миллионов загрузок ежемесячно.
Вредоносный код действовал незаметно. Он собирал чувствительные данные — от SSH-ключей до облачных токенов — и отправлял их на сервер злоумышленников.
Особую опасность представляла механика атаки:
- в одной версии вредоносный код запускался при импорте библиотеки;
- в другой — автоматически при старте Python благодаря .pth-файлу.
Фактически достаточно было установить пакет, чтобы система оказалась под угрозой.
Как произошёл взлом
Атака стала частью более широкой кампании. Хакеры из группы TeamPCP использовали цепочку компрометаций:
сначала взломали инструменты безопасности (например, Trivy), а затем через CI/CD-процессы получили доступ к учетным данным разработчиков.
После этого они опубликовали заражённые версии LiteLLM напрямую в PyPI, минуя стандартный процесс релизов.
Такая схема — классический пример атаки на цепочку поставок, когда доверие к инструментам разработки оборачивается уязвимостью.
Где здесь Delve
На фоне расследования всплыл ещё один важный факт: ранее LiteLLM проходила аудит соответствия (SOC 2), который проводила компания Delve.
Именно этот момент вызвал особое внимание. Получается, проект с подтверждённой «безопасностью» оказался уязвим к одной из самых серьёзных атак последних месяцев.
Критики отмечают, что доверие к таким аудитам может быть переоценено. В случае Delve речь идёт о компании, которую уже обвиняли в использовании шаблонных отчётов и формальном подходе к проверкам.
В результате складывается парадоксальная ситуация:
разработчики доверяли LiteLLM из-за наличия сертификатов, а сами сертификаты — продукт системы, чья надёжность теперь под сомнением.
Почему это важно
Инцидент с LiteLLM стал не просто очередной историей про вредоносный код. Он показал сразу несколько системных проблем:
- зависимость разработчиков от сторонних библиотек и инструментов;
- уязвимость CI/CD-цепочек;
- ограниченную эффективность формальных аудитов безопасности.
Кроме того, атака продемонстрировала, что даже популярные проекты с проверенной репутацией могут стать точкой входа для масштабного компрометационного сценария.
Что дальше
После инцидента разработчики LiteLLM удалили заражённые версии и сменили ключи доступа. Эксперты советуют всем, кто мог установить уязвимые версии, считать свои данные скомпрометированными и срочно менять ключи и токены.
Но главный вывод шире: сама модель доверия — от open-source до compliance-аудитов — требует пересмотра.