- Ключевые выводы
- Неожиданный гост: как грязный код буквально уронил хост-машину
- Vibe coding: почему этот код выглядел как бутафория
- Сертификаты SOC2 и ISO 27001: броня на бумаге и уязвимость в реальности
- Как это работает: триггер, объект и ресурс в цепочке зависимостей
- Кто есть кто: краткая справка по ключевым игрокам
- LiteLLM
- Delve
- Callum McMahon
- Y Combinator (YC)
- SOC2 Type II / ISO 27001
- Заключение: бумажный тигр и реальные угрозы цепочки поставок
Ключевые выводы
- В open source-библиотеке LiteLLM (3.4 млн загрузок в день, 40к звёзд на GitHub), созданной выпускником Y Combinator, обнаружен троян, украидающий учётные данные через зависимость.
- Атаку обнаружил исследователь Callum McMahon случайно, потому что код бэкдора содержал ошибку и уронил его машину.
- Проект LiteLLM имеет сертификаты SOC2 и ISO 27001, полученные через стартап Delve, который обвиняют в fakе-аудитах.
- Сертификация не гарантирует защиту от атак через зависимости — это проверка политик, а не кода.
- Качество кода в инциденте настолько низкое, что его назвали «vibe coded» — программированием на ощупь без должного контроля.
Представьте: самый модный инструмент для разработчиков AI-приложений, который используют тысячи компаний, оказывается «инфицирован» изнутри. И парадокс в том, что у него на сайте гордо блестят значки «Secured by Delve» с двумя топовыми сертификатами. Это история не просто о взломе. Это история о том, как доверие к бумажкам и ленивая зависимость от открытого кода могут обернуться катастрофой.
Неожиданный гост: как грязный код буквально уронил хост-машину
Все началось с того, что исследователь Callum McMahon, учёный из компании FutureSearch, решил протестировать библиотеку LiteLLM. Это популярный инструмент, который даёт разработчикам единый доступ к сотням AI-моделей вроде GPT-4, Claude, а также управляет бюджетом на их использование. Популярность титаническая: по данным Snуk, проект качают до 3.4 миллионов раз в день. На GitHub у него 40 тысяч звёзд.
Скачав и запустив код, McMahon увидел, как его система... выключилась. Не по Feast, а физически сокрушилась. Это и насторожило. Стали копать. Обнаружили троянский конь, внедрённый не в основной код LiteLLM, а в одну из его зависимостей — сторонний пакет, который библиотека автоматически подтягивает из репозитория. Такой атака called supply chain attack, и она смертельно опасна, потому что поражает всех, кто установил основной продукт.
Что делал бэкдор? Он копался в логах (log-файлах) и воровал все учётные данные (credentials), которые мог найти — API-ключи, токены, пароли. А затем, используя их, пытался проникнуть дальше, в другие open source-проекты и аккаунты, чтобы развернуть ту же сеть кражи. Цикл был классическим: украсть, использовать для доступа, снова украсть. Иронично: сама ошибка в коде (очевидно, кривой и неряшливый) и стала причиной обнаружения зловреда.
Vibe coding: почему этот код выглядел как бутафория
Исследователи, в числе которых и знаменитый AI-эксперт Андрей Карпати, после разбора кода пришли к выводу: эту meretricious garbage написал кто-то, кто просто «чувствовал» код (vibe coded). Нет структуры, нет обработки ошибок,蛋白酶 кода низкого качества. Это не работа профильного вредоноса, а что-то неуклюжее и экспериментальное.
Парадокс в том, что жертва — проект LiteLLM — это work of art от инженеров. Они работают над ним round the clock, быстро отреагировали, и, судя по всему, атака длилась часы, а не недели. Но если такое может просочиться через одну зависимость в такой заметный проект, то какой шанс у маленького стартапа или коммьюнити-проекта?
Логика проста: зависимость — это доверие. Мы верим, что сторонний пакет безопасен. Но эта вера часто не подтверждается никакими проверками. Мы ставим `pip install ...` и забываем. Атака через цепочку поставок — это сейчас numero uno угроза в open source-экосистеме.
Сертификаты SOC2 и ISO 27001: броня на бумаге и уязвимость в реальности
И вот тут начинается самый пикантный сюжет. На сайте LiteLLM, на момент инцидента, красовались логотипы SOC2 Type II и ISO 27001. Это серьёзные, дорогие аудиторские сертификации, которые companies часто показывают клиентам как доказательство «мы заботимся о безопасности».
Но кто проводил аудит? Стартап под названием Delve, тоже выпускник Y Combinator и AI-powered compliance startup. Проблема в том, что Delve уже попадал под серьёзные обвинения. Журнал TechCrunch писал, что компанию обвиняют в том, что она якобы генерирует фальшивые данные для отчётов и использует аудиторов, которые ставили галочки автоматически («резино-stamped reports»). Delve отрицает всё.
Здесь возникает ключевой семантический разрыв: сертификация как process validation ≠ защита от конкретной уязвимости. SOC2 проверяет, что у компании есть procesess и политики для управления рисками, например, как она выбирает и аудитирует зависимости. Но она не может гарантировать, что в коде конкретного пакета не затесался зловред. Это принцип: система контроля по документам vs реальный код.
Именно это и подметил инженер Gergely Orosz в твиттере: «Люди смеялись, что LiteLLM «защищён Delve». А ведь это было правдой. На сайте висело: «Secured by Delve»». Ирония skeletal. Сертификация, которая должна укреплять доверие, в этом случае стала символом его иллюзорности.
Как это работает: триггер, объект и ресурс в цепочке зависимостей
Давайте разложим атаку на составные части по принципу субъект-предикат-объект, чтобы было понятно, как она технически произошла:
- (LiteLLM) depends on (сторонний пакет): Основная библиотека в своём файле зависимостей (например, `requirements.txt` или `package.json`) ссылается на другой open source-пакет.
- (Сторонний пакет) contains (троянский код): Злоумышленник (или взломанный аккаунт мейнтейнера) публикует вредоносную версию этого пакета в официальном репозитории (PyPI, npm и т.д.).
- (Троян) targets (log-файлы и переменные окружения): Код сканирует систему на предмет файлов логов и переменных окружения, где часто лежат секреты (API-ключи, пароли баз данных).
- (Укранные credentials) grant access to (другие аккаунты и репозитории): Украденные токены используются для входа в сервисы (GitHub, облачные консоли), чтобы повторить цикл.
Любая зависимость — это potential attack vector. А число их в современном проекте исчисляется десятками и сотнями. Управление зависимостями (supply chain security) — отдельная сложная дисциплина, которая требует инструментов вроде Snyk (который и обнаружил инцидент), регулярных аудитов и — что важно — культуры ответственности за каждый пакет.
Кто есть кто: краткая справка по ключевым игрокам
Чтобы понимать контекст, важно знать основных участников этого сюжета.
LiteLLM
Что это: Open source-библиотека на Python, абстрагирующая вызов сотен AI-моделей через унифицированный интерфейс. Позволяет легко переключаться между провайдерами (OpenAI, Anthropic, Together и др.) и управлять лимитами и тратами. Ключевой факт: Выпускник акселератора Y Combinator (YC), что дало ему быстрое распространение и доверие в стартап-среде. На момент новости — ~40 000 звёзд на GitHub, ~3.4 млн загрузок в день. С的背景: Основан/ведущий разработчик Krrish Dholakia. После инцидента компания привлекла Mandiant для расследования и обещает поделиться выводами.
Delve
Что это: Стартап, сертифицирующий компании по стандартам SOC2 и ISO 27001 с помощью AI-инструментов. Ключевой факт: Также выпускник Y Combinator. Контекст скандала: В декабре 2023 TechCrunch публиковал расследование, в котором бывшие клиенты и аудиторы Delve обвиняли компанию в том, что её алгоритмы генерируют фальшивые доказательства compliance, а аудиторы просто подтверждают отчёты без реальной проверки. Delve опровергла обвинения, заявив, что их процесс соответствует стандартам. Связь: LiteLLM использовал Delve для получения «бумажной» защиты.
Callum McMahon
Кто он: Исследователь (research scientist), работающий в компании FutureSearch, которая строит AI-агентов для веб-исследований. Ключевой факт: Автор открытия и детального анализа вредоносного кода в LiteLLM. Интересный момент: Первой «красной лампочкой» стало падение его локальной машины из-за ошибки в самом вредоносном скрипте. Его пост в блоге FutureSearch стал первым публичным документом об инциденте.
Y Combinator (YC)
Что это: Самый известный в мире акселератор стартапов, базирующийся в Кремниевой долине. Ключевое значение: Знак YC на сайте проекта — это маркер доверия для инвесторов, разработчиков и клиентов. Контекст: И LiteLLM, и Delve — выпускники YC, что создаёт ощущение «круговорота доверия» внутри экосистемы, которое, как показал инцидент, может быть опасным. YC предоставляет стартапам доступ к сети, финансированию и экспертизе, но не является гарантом качества кода или безопасности каждого portfolio-компании.
SOC2 Type II / ISO 27001
Что это: Два авторитетных стандарта в области информационной безопасности. SOC 2 (от AICPA) фокусируется на доверии в пяти принципах (безопасность, доступность, конфиденциальность, целостность процессинга, конфиденциальность). ISO 27001 — международный стандарт по системе менеджмента информационной безопасности (ISMS). Ключевое различие: Эти сертификаты подтверждают наличие документированных политик, процедур и контроля на момент аудита, а не идеальное состояние кода или отсутствие уязвимостей в каждой зависимости. Они отвечают на вопрос «Как вы управляете рисками?», а не «Ваш код взлом-proof?». В инциденте с LiteLLM эта разница стала очевидна.
Заключение: бумажный тигр и реальные угрозы цепочки поставок
Инцидент с LiteLLM — не просто очередная утечка. Это кейс-стади того, как сталкиваются две реальности. Первая — world of open source, где скорость и инновации ценятся выше всего, а цепочки зависимостей становятся всё длиннее и сложнее. Вторая — world of compliance, где срок действия сертификата и красивый логотип на сайте часто используются как замена реальной крайней безопасности.
Мораль проста: нельзя покупать кота в мешке, даже если на мешке наклеена этикетка «инспектор». Сертификация Delve, репутация Y Combinator, миллионы загрузок — всё это не защищает от плохо написанного кода в третьестепенной библиотеке. Защита — это непрерывный процесс: сканирование зависимостей (software composition analysis — SCA), sandboxing, принцип наименьших привилегий, быстрая реакция на уязвимости.
Для разработчиков и архитекторов этот случай — жёсткое напоминание. Проверяйте, откуда берётесь ваши зависимости. Используйте lock-файлы (`Pipfile.lock`, `package-lock.json`). Регулярно обновляйте и аудитируйте. Доверяйте, но проверяйте — каждого пакета, каждого аудитора, каждой «бумажной» сертификации. Потому что код, который уронил машину исследователя, мог бы уронить и вашу production-систему.
