Как инструменты ИИ для программирования могут усилить атаки на цепочки поставок ПО
- Bloom обнаружила более 1 500 уязвимых npm-пакетов Trusted Publishing с совокупными 10 млн загрузок; повторная регистрация GitHub-слага могла дать доступ к публикации без кражи учётных данных.
- По оценке Bloom, ИИ-агенты устанавливают около 70 пакетов в месяц на обычное устройство и до 350 — на компьютер разработчика.
- Bloom сообщила об уязвимости GitHub 6 июня 2026 года; перед публикацией исследования компания обнаружила, что npm уже внедрила исправление.
Почему это важно: ИИ-агенты могут автоматически устанавливать последние версии пакетов, а их хуки postinstall способны запускать вредоносный код на компьютерах разработчиков и в системах непрерывной интеграции.
Инструменты для написания кода на основе ИИ меняют подход разработчиков к получению и использованию программного обеспечения. Однако растущий объём автоматизированных установок пакетов создаёт новые проблемы для корпоративных команд безопасности. Уязвимость, обнаруженная компанией Bloom Security, показывает, как слабые места в инфраструктуре публикации ПО могут сочетаться с такими автоматизированными процессами. В результате организации могут подвергнуться воздействию вредоносного кода — и злоумышленникам при этом не придётся похищать учётные данные.
В ходе исследования под названием SlugFest было выявлено более 1 500 npm-пакетов, уязвимых к атаке на публикацию, связанной с адресами репозиториев GitHub. В совокупности эти пакеты набрали более 10 миллионов загрузок.
Bloom также оценила масштабы установки программного обеспечения с помощью ИИ в крупных компаниях. Выяснилось, что на типичное конечное устройство ежемесячно устанавливается около 70 пакетов через ИИ-агентов. На компьютерах разработчиков это число может приближаться к 350.
Эти выводы заставляют задуматься о том, как организациям следует управлять программными зависимостями. ИИ-агенты всё чаще самостоятельно выбирают, устанавливают и запускают код.
Новый уровень угроз для компаний
Bloom изучила поведение миллионов ИИ-агентов в десятках организаций. Согласно исследованию, отдельные агенты устанавливают от 0,3 до 1,2 пакета в день — в зависимости от типа агента. На компьютерах разработчиков активность выше: ежедневно они устанавливают напрямую от двух до трёх пакетов.
В среднем на одном конечном устройстве работают три агента — через интерфейсы командной строки, IDE, расширения и помощников. На компьютерах разработчиков их может быть пять и больше. Эти цифры не учитывают дополнительные зависимости, которые устанавливают пакеты, загруженные напрямую. Поэтому общий объём программного обеспечения может превышать указанные значения.
Такая активность повышает вероятность проникновения в среду недоверенного кода. Пакеты могут запускать сценарии установки, включая хуки postinstall, и разработчик не обязательно проверяет каждую зависимость по отдельности.
Bloom сообщила, что обнаружила и заблокировала попытку ИИ-агента клиента установить один из пакетов, затронутых уязвимостью. Этот инцидент наглядно показал, как автоматизированные процессы разработки пересекаются с рисками для цепочки поставок ПО, описанными в исследовании.
Механизм публикации, создавший угрозу
Уязвимость была связана с механизмом npm Trusted Publishing. Он призван повысить безопасность, заменив долгосрочные токены публикации краткосрочными учётными данными.
При таком механизме рабочий процесс GitHub Actions получает от GitHub токен OpenID Connect. Затем он обменивает его в npm на временные учётные данные для публикации. Такой подход снижает зависимость от статических секретов, которые в противном случае могли бы раскрыться в системах сборки или журналах.
Однако Bloom выяснила, что изначально npm устанавливала доверительные отношения на основе удобочитаемого адреса репозитория GitHub — его слага. Постоянный идентификатор репозитория при этом сразу не сохранялся.
Это различие становится важным, когда владельцы переименовывают репозитории, передают их другим или удаляют. Старые адреса могут стать доступны для повторной регистрации. Привязка Trusted Publisher пакета при этом может по-прежнему ссылаться на прежний адрес, а успешная публикация ещё могла не состояться. В таком случае другой репозиторий потенциально способен соответствовать исходной конфигурации доверия.
Это позволяет получить доступ к публикации. Для этого не нужно похищать учётные данные законного сопровождающего пакета или взламывать его аккаунт GitHub.
Как одна уязвимость может затронуть зависимые проекты
Bloom продемонстрировала проблему, используя контролируемые исследователями репозитории GitHub и пакет npm в области имён, принадлежащей исследователям. Команде удалось опубликовать пакет из второго репозитория, принадлежавшего другой организации. Единственным общим элементом был слаг репозитория, который стал доступен для повторной регистрации.
Получив доступ к публикации, злоумышленник может выпустить вредоносную версию под именем легитимного пакета. Число загрузок, репутация и связи с зависимыми проектами при этом сохраняются за этим именем.
Следующий этап — распространение. ИИ-агенты могут автоматически разрешать зависимости и устанавливать последние доступные версии. Не обязательно, чтобы кто-то проверял происхождение каждого пакета или историю его выпусков. Если в вредоносный релиз включён хук postinstall, его код может выполниться при установке на компьютерах разработчиков или в системах непрерывной интеграции.
В исследовании также описана потенциальная уязвимость при проверке происхождения пакетов. Вредоносный релиз может содержать аттестацию, связанную с репозиторием самого злоумышленника. Некоторые системы проверяют лишь наличие аттестации, не выясняя, совпадает ли её источник с репозиторием ожидаемого сопровождающего. В результате они могут не выявить несоответствие.
Что эти выводы означают для руководителей служб безопасности
В ходе сканирования реестра Bloom выявила более 1 500 уязвимых пакетов. На них пришлось свыше 10 миллионов загрузок в совокупности и более миллиона загрузок в месяц. Исследователи подчеркнули, что речь идёт о пакетах, настроенных для Trusted Publishing, — лишь части экосистемы npm.
Для руководителей корпоративных служб безопасности эти выводы говорят о том, что одних лишь перечней зависимостей может быть недостаточно. Автоматизированная установка программного обеспечения несёт собственные риски. Bloom рекомендует проводить аудит установленного ПО за пределами традиционных пакетов, включая расширения, приложения, плагины, репозитории, MCP и навыки.
Компания также рекомендует внедрить межсетевой экран для цепочки поставок, контролирующий, что именно попадает в корпоративную среду, и разработать правила, позволяющие сотрудникам безопасно использовать ИИ-агентов.
У сопровождающих пакеты есть и отдельная обязанность — проверять разрешения на публикацию. Bloom рекомендует запустить npm trust list и убедиться, что каждый настроенный адрес репозитория по-прежнему ведёт к репозиторию, который находится под их контролем. Также рекомендуется заново создавать привязки доверия после переименования или передачи репозитория. При удалении привязанного репозитория следует также удалить связанную с ним конфигурацию доверия, если она больше не нужна.
Исправление уязвимости спустя более чем 120 дней
6 июня 2026 года Bloom сообщила об уязвимости через программу GitHub HackerOne. GitHub провела первичную оценку и подтвердила проблему 9 июня. Последний ответ до того, как уязвимость в итоге устранили, поступил 8 июля.
После ещё шести обращений, включая запрос на посредничество, Bloom начала готовиться к публикации результатов исследования. Перед публикацией компания направила свои выводы в npm и повторно провела тест атаки. Выяснилось, что npm уже внедрила исправление. Впоследствии npm подтвердила устранение уязвимости и извинилась за задержку с ответом.
Предложенное Bloom решение заключалось в том, чтобы при установлении доверия сохранять неизменяемые идентификаторы репозитория и его владельца, а затем проверять идентификатор репозитория в токене OIDC при авторизации публикации. Исследователи отметили, что в PyPI Warehouse уже применяется такой подход, а проблема также затрагивала реализацию GitLab Trusted Publishing в npm.
Главная проблема не в том, что автоматизированная публикация или инструменты для написания кода на основе ИИ сами по себе небезопасны. Исследование показывает, как автоматизация разработки может усугубить последствия нарушения доверительных отношений.
По мере того как создание программного обеспечения становится всё более автономным, организации должны следить за тем, чтобы системы публикации и установки кода проверяли, как называется его источник. Но также важно удостоверяться, что это именно тот источник, которому они намеревались доверять.
