Bloom Security нашла уязвимость в публикации пакетов, а ИИ-агенты множат риск

В 2025 году исследователи проверили 576 тысяч фрагментов кода, написанных 16 моделями. В среднем 19,7% рекомендованных пакетов вообще не существовали. Эти имена можно зарегистрировать и наполнить вредоносным кодом, а потом ждать, пока ИИ-ассистент сам подтянет их в проект. Теперь у проблемы появился ещё один слой: компания Bloom Security описала уязвимость в инфраструктуре публикации ПО, которая в связке с автоматическими установками может доставить вредоносный код в корпоративную среду. Об этом пишет The Next Web.

Что известно об уязвимости

Известно следующее: Bloom Security нашла слабое место в механизмах публикации пакетов, и оно становится опаснее, когда установкой зависимостей занимается не человек, а ИИ-агент. Судя по адресу материала, речь идёт о механизме Trusted Publishing в npm. Это схема, при которой пакет публикуется из доверенного CI-процесса без долгоживущих токенов. Идея разумная: токены воруют регулярно, и после волны атак на npm в 2025 году, включая червя Shai-Hulud, который затронул сотни пакетов, экосистема всерьёз пересматривала практики публикации.

Уязвимость в самом механизме доверия бьёт по базовому допущению: если пакет опубликован «правильным» способом, ему можно верить. Агент это допущение разделяет и проверять не станет.

Почему агенты меняют масштаб

Человек, который ставит зависимость, обычно хотя бы мельком смотрит на название, число загрузок, репозиторий. Агент работает иначе: ему нужно, чтобы тесты прошли, а сборка собралась. Если пакет решает задачу, он окажется в `package.json` за секунды.

Три фактора усиливают друг друга:

• Скорость. Агент может поставить десятки зависимостей за одну сессию, и каждая становится точкой входа.
• Галлюцинации имён. Около 20% несуществующих пакетов в выдаче моделей, по данным исследования 2025 года, создают поле для атаки через регистрацию похожих названий.
• Права. Агенты нередко работают в окружении с доступом к секретам, CI и внутренним репозиториям, а скрипты установки npm выполняются сразу.

Уязвимость в публикации добавляет к этому ещё один вектор: даже корректное имя пакета перестаёт гарантировать безопасность.

Кого это касается

Больше всего рискуют команды, где ИИ-кодинг встроен в рабочий процесс без отдельной политики для зависимостей: стартапы с быстрым циклом релизов, подрядчики, внутренние платформенные команды. Корпоративные службы безопасности привыкли контролировать людей и пайплайны, а агент стоит между ними и обходит оба уровня контроля.

Пока неясно, насколько широко брешь использовалась на практике и какие версии затронуты. Эти вопросы стоит задать поставщику реестра и самим исследователям.

Что сделать уже сейчас

Сначала стоит выяснить, какие агенты в компании могут выполнять `npm install` и в каком окружении. Если это машина разработчика с токенами и доступом к приватным репозиториям, это первая зона для ограничений.

Дальше работают проверенные меры:

• включить lock-файлы и запретить агентам менять их без ревью;
• отключить выполнение install-скриптов (`--ignore-scripts`) там, где они не нужны;
• завести allowlist зависимостей или внутреннее зеркало реестра с задержкой на новые версии;
• проверять новые пакеты по возрасту, числу мейнтейнеров и источнику сборки;
• запускать агентов в изолированных песочницах без постоянных секретов.

Главный вывод простой: доверие к реестру нужно проверять так же, как доверие к коду, а скорость агента не должна быть выше скорости проверки.