КРАТКО
Компания Upwind первой публично сообщила о том, что keyv@6.0.0 — широко используемый пакет npm с 154 миллионами загрузок в неделю — содержал вредоносный preinstall-скрипт, который похищал учетные данные AWS, токены GitHub и токены аутентификации npm. Эта атака обошла легитимные конвейеры сборки и проверки происхождения ПО. Позже кампания расширилась на сотни пакетов. Upwind рекомендует организациям удалить скомпрометированную версию, сменить учетные данные и провести аудит файл-локеров.
В течение многих лет атаки на цепочки поставок программного обеспечения были сосредоточены на взломе широко распространенных приложений уже после их развертывания. Однако злоумышленники все чаще смещают свое внимание дальше по цепочке, нацеливаясь на open-source пакеты, на которые разработчики полагаются каждый день. Последний пример произошел, когда компания Upwind первой выявила и публично сообщила о вредоносном релизе популярного пакета Keyv для npm, предупредив, что этот взлом может затронуть организации далеко за пределами одного проекта.
Это открытие стало очередным напоминанием о том, что популярность может стать уязвимым местом в экосистеме открытого исходного кода. Пакет, которому доверяют миллионы разработчиков, может быстро превратиться в эффективный канал распространения вредоносного ПО, если злоумышленникам удастся скомпрометировать хотя бы один релиз.
Скрытый риск в рутинном обновлении
На первый взгляд релиз выглядел ничем не примечательным. Однако расследование Upwind показало, что версия keyv@6.0.0 содержала вредоносный preinstall-скрипт, который выполнялся автоматически при установке пакета.
«Наш анализ выявил вредоносный релиз keyv@*, который добавляет новый хук предварительной установки (preinstall), выполняющий обфусцированный загрузчик во время инсталляции,» — сообщили в Upwind.
Вместо немедленной установки пакета загрузчик сначала скачивал среду выполнения Bun из репозитория GitHub Releases, а затем запускал упакованную полезную нагрузку. По данным Upwind, эта полезная нагрузка пыталась собрать конфиденциальные учетные данные с рабочих станций разработчиков и из сред непрерывной интеграции (CI), включая учетные данные AWS, токены GitHub, токены аутентификации npm и секреты HashiCorp Vault.
Эта атака примечательна не тем, что она эксплуатировала уязвимость в программном обеспечении, а тем, что она злоупотребляла доверием разработчиков к менеджерам пакетов и автоматическим обновлениям зависимостей.
Почему одна зависимость может затронуть тысячи организаций
Keyv трудно назвать нишевой библиотекой. Этот пакет регистрирует около 154 миллионов загрузок каждую неделю, что делает его распространенной зависимостью для самых разных приложений на JavaScript — от стартапов до корпоративного софта.
«Что делает этот инцидент особенно значимым, так это масштаб распространения пакета,» — пояснили в Upwind. — «Имея примерно 154 миллиона еженедельных загрузок, keyv является фундаментальной зависимостью, используемой в тысячах проектов на JavaScript, что резко увеличивает потенциальный радиус поражения от взлома.»
Такой масштаб помогает объяснить, почему атаки на цепочки поставок становятся все более привлекательными. Вместо того чтобы атаковать отдельные компании по очереди, злоумышленники могут скомпрометировать программное обеспечение, которое множество организаций устанавливают автоматически в рамках существующих рабочих процессов разработки.
Последующие отчеты показали, что кампания вышла за рамки первоначального релиза Keyv: вредоносные версии появились во множестве пакетов npm. По мере развития ситуации мейнтейнеры пакетов удаляли скомпрометированные релизы и восстанавливали чистые версии, из-за чего точная оценка степени заражения стала зависить от проверки lock-файлов и разрешенных версий зависимостей, а не просто от проверки последней доступной в реестре версии пакета.
Пределы безопасности, основанной на доверии
Этот инцидент также преподносит важный урок для современной разработки программного обеспечения: доверенная инфраструктура не обязательно гарантирует доверенное ПО.
Согласно отчетам, вредоносный пакет прошел через легитимную автоматизацию релизов, включая подтверждение происхождения ПО (provenance), сгенерированное устоявшимися конвейерами сборки. Эти меры защиты проверяли целостность самого процесса сборки, но они не могли определить, попал ли вредоносный код в исходный код еще до начала сборки.
Для команд безопасности это различие приобретает все большую важность. Традиционные средства защиты цепочки поставок ПО помогают подтвердить подлинность, но они менее эффективны при обнаружении вредоносного поведения, встроенного в легитимные релизы.
Поскольку организации продолжают масштабное внедрение программного обеспечения с открытым исходным кодом, стратегии безопасности все чаще должны включать мониторинг поведения зависимостей в реальном времени (runtime), особенно во время установки, когда вредоносные скрипты жизненного цикла могут выполниться еще до запуска самого приложения.
Растущая проблема для разработки программного обеспечения
Upwind посоветовала организациям, использующим Keyv, немедленно удалить keyv@6.0.0, зафиксировать версии зависимостей на проверенном чистом релизе, сменить учетные данные, если вредоносный пакет был установлен, а также проверить конвейеры CI/CD, lock-файлы и спецификации состава ПО (SBOM) на предмет признаков заражения.
«Этот инцидент служит еще одним напоминанием о том, что высоконадежные зависимости с большим объемом загрузок остаются главными мишенями для злоумышленников, атакующих цепочки поставок, и что один единственный вредоносный релиз может иметь последствия для всей экосистемы,» — заявили в компании.
Поскольку цепочки поставок программного обеспечения становятся все более крупными и взаимосвязанными, подобные атаки на Keyv, вероятно, будут происходить все чаще. Инцидент демонстрирует, что защита современных приложений требует мониторинга не только кода, который организации пишут самостоятельно, но и доверенных компонентов, унаследованных из более широкой экосистемы open-source. Раннее обнаружение вредоносного релиза компанией Upwind показало, как быстро рутинное обновление пакета может превратиться в масштабный инцидент безопасности и почему видимость зависимостей ПО теперь так же критически важна, как и видимость производственных систем.
Опубликовано 4 августа 2026 - 09:06 Наверх
