CrowdStrike, Google и Shadowserver остановили GlassWorm, но автоматический шум мешает защите open source
GlassWorm остановили, но изолированные операции все чаще выглядят временными
Когда-то вывод из строя масштабной вредоносной операции считался заметным успехом в защите open-source-экосистемы. Теперь это почти не вызывает реакции. Нейтрализация кампании GlassWorm произошла в момент, когда атакующие могут быстро восстановить инфраструктуру, а защитники все чаще сталкиваются с новой проблемой: как отличить реальные угрозы от автоматизированного шума.
«Я считаю, что скоординированные действия, такие как GlassWorm, могут разорвать контроль, существенно увеличить издержки атакующих, выиграть время для устранения последствий и показать, что возможен ответный удар», — сказал Агнидита Саркар, главный евангелист ColorTokens. «Но большинство операций по выводу инфраструктуры из строя — это временные меры в долгой борьбе».
Операция по нейтрализации, которую вели CrowdStrike, Google и Shadowserver Foundation, нарушила работу инфраструктуры, связанной с кампанией, которая отравила сотни репозиториев вредоносными пакетами, нацеленными на разработчиков.
На следующий день после операции база данных OSV отозвала 157 отчетов о вредоносном ПО после того, как сопровождающие проект пришли к выводу, что эти записи, вероятно, были автоматическими ложноположительными срабатываниями.
Операции по выводу из строя помогают, но аналитики сомневаются в долгосрочном эффекте
Операция прошла 26 мая в 14:00 UTC; CrowdStrike подтвердила, что были одновременно отключены «все четыре канала command-and-control (C2) GlassWorm». Это, как сообщается, помогло отрезать операторов botnet от зараженных машин и помешало им распространять новое вредоносное ПО.
CrowdStrike описала GlassWorm как операцию, нацеленную на инфраструктуру для распространения вредоносного ПО через репозитории, ориентированные на разработчиков, — все более популярный вектор атак, поскольку злоумышленники стремятся получить доступ к CI/CD, учетным данным разработчиков и далее — к корпоративной среде.
GlassWorm была кроссплатформенной операцией и затрагивала Windows, macOS и Linux; в атаке использовались троянизированные расширения VSCode и скомпрометированные пакеты npm и Python для сбора информации и учетных данных.
«В рамках наших усилий по нарушению работы мы вместе с партнерами стараемся причинять атакующим больше проблем, особенно когда видим, что они злоупотребляют нашими продуктами или нацеливаются на наших пользователей», — сказал главный аналитик Google Threat Intelligence Group (GTIG) Джон Хулткист в посте на X.
Однако экономика злоупотреблений репозиториями в целом не изменилась. Open-source-экосистемы по-прежнему дают атакующим дешевые каналы распространения, огромный охват и сравнительно слабую проверку идентичности по сравнению с традиционными каналами распространения ПО. Это означает, что операторы кампаний вроде GlassWorm нередко быстро возвращаются под новыми учетными записями, доменами или названиями пакетов.
«Это нарушение работы, а не уничтожение», — предупредил Саркар. «Чтобы повысить устойчивость после такой операции, защитникам следует быстро сканировать систему после вывода из строя, чтобы обнаружить повторное появление вредоносных артефактов в связанных репозиториях и на каналах распространения».
Затем им следует выстраивать гранулярные micro-perimeters, развивать возможности по сдерживанию распространения между workloads, endpoints, IT/OT/IoT/cloud-активами и ограничивать радиус поражения supply-chain-компрометаций — например, чтобы отравленный пакет npm или GitHub workflow, крадущий учетные данные, не мог легко перейти к следующему этапу атаки.
Саркар рекомендовал разработчикам и организациям создавать «гранулярные micro-perimeters», развивать возможности по сдерживанию распространения между workloads и ограничивать радиус поражения supply-chain-компрометаций.
Ложноположительные срабатывания ИИ становятся частью проблемы supply chain
Если GlassWorm показывает устойчивость реальных вредоносных кампаний, то инцидент с отзывом записей OSV выявил параллельную проблему в supply chain open-source software (OSS): растущую ненадежность автоматизированной безопасности.
Отзыв 157 отчетов о вредоносном ПО, которые, как считается, были сгенерированы ИИ как ложноположительные срабатывания, имеет значение, особенно если в список попадают такие пакеты, как FastAPI v0.136.3. FastAPI — широко используемый Python framework, который лежит в основе production APIs, AI-сервисов и cloud-native-приложений в разных отраслях. Даже несколько дней ложной пометки могут вызвать дорогие задержки развертывания, сбои в CI/CD и часы работы разработчиков, уходящие на отделение легитимного ПО от ложной тревоги.
«Я бы рекомендовал предприятиям достаточно серьезно относиться к проблемам signal-to-noise, чтобы рассматривать меры по их исправлению, поскольку автоматизация подрывает доверие к защитным инструментам», — сказал Саркар. «Если у вас не очень глубоко сегментированное предприятие, шум тратит время аналитиков, замедляет скорость работы и повышает риск пропустить сложные атаки из-за усталости».
В 2026 году, когда ИИ-ассистированное вредоносное ПО и автоматизированные отчеты одновременно ускоряются, а в инструментах SAST/SCA растет число ложноположительных срабатываний, защитная автоматизация все сильнее усложняется из-за объема supply chain, отметил он.
В блоге Socket назвала плохие записи OSV особенно опасными, поскольку популярная база данных быстро распространяется через dependency scanners, CI checks, registry controls, SBOM tools, dashboards и внутренние policy systems.
Но поводы для оптимизма есть: новые инструменты обещают меньше полагаться на ИИ при поиске уязвимостей зависимостей. CVE Lite CLI, легковесный сканер уязвимостей зависимостей для JavaScript и TypeScript, дает разработчикам возможность узнавать о рисках зависимостей еще в процессе написания кода, гораздо раньше, чем при провале автоматических сканеров в CI pipelines.
Оригинал статьи опубликован на CSO.
Материал — перевод статьи с английского.
Оригинал: Supply chain battles intensify as takedowns meet AI-driven noise