Представьте: вы обновляете dependency в своём проекте, как делали сотню раз, а через несколько часов продакшен падает, файлы на сервере превращаются в «сердечки», а в логах — бесконечный поток

Представьте: вы обновляете dependency в своём проекте, как делали сотню раз, а через несколько часов продакшен падает, файлы на сервере превращаются в «сердечки», а в логах — бесконечный поток символов. Знакомо? Если нет, то это лишь вопрос времени. Речь не о банальном вирусе, а о protestware — коде, который разработчики осознанно внедряют в open-source библиотеки, чтобы выразить свою политическую или социальную позицию. В отличие от классических злоумышленников, здесь не нужны деньги — только идея. Но последствия для бизнеса могут быть не менее катастрофическими: отказ сервисов, потеря данных, репутационный ущерб и простой CI/CD.

Как это работает? Самый громкий случай — библиотека node-ipc, которую использовали тысячи проектов для межпроцессного взаимодействия. В марте 2022 года её автор добавил зависимость peacenotwar. При установке пакета на машинах с IP-адресами из России или Беларуси модуль определял геолокацию, а затем перезаписывал все файлы на диске на символы «мира» — сердечки. Вдобавок на рабочий стол падал файл WITH-LOVE-FROM-AMERICA.txt. Причём код был спрятан в postinstall-хуке и обфусцирован, поэтому антивирусы молчали.

Второй пример — библиотека colors, популярная для раскрашивания вывода в терминал. Один из мейнтейнеров добавил в неё бесконечный цикл с выводом не-ASCII символов. Любой `require('colors')` блокировал event loop Node.js, и приложение просто зависало. Это классический DoS. Третий кейс — es5-ext, низкоуровневая утилита, которую тянет webpack. Здесь мейнтейнер встроил проверку времени и локали: если часы показывали с 22:00 до 06:00 или система работала в локали ru_RU, код запускал бесконечный цикл, нагружая CPU на 100%.

Что важно понимать? Protestware не обязательно «взрывное». Оно может «спать» месяцами и активироваться по нужному условию: дата, регион, переменные окружения, hostname, язык клавиатуры. Иногда вредоносная логика находится в метаданных пакета и тянет инструкции с удалённого сервера. А часто — это вообще не про вредоносность: просто баннер с петицией или политическим лозунгом. Но и такое — уже риск для репутации продукта.

Как обнаружить угрозу до того, как она сработала? Универсального детектора нет, но есть набор индикаторов. Во-первых, подозрительные проверки геолокации или региональных настроек в коде библиотеки. Во-вторых, необъяснимые сетевые запросы к внешним API, особенно геосервисам. В-третьих, операции с файловой системой, не соответствующие назначению пакета. И наконец, обфускация. Легитимные библиотеки редко намеренно запутывают свой код — если видите такое, насторожитесь.

Инструменты анализа цепочки поставок помогают систематизировать проверку. OSA (анализ открытого исходного кода) позволяет сверить пакеты со списками «токсичных» репозиториев. SCA-композиционный анализ строит полный перечень зависимостей и выявляет известные вредоносные пакеты. Статический анализ ищет опасные паттерны: `execSync`, `rm -rf`, `geoip`, `locale` и прочее. Динамический анализ запускает приложение в песочнице и смотрит, какие файлы, сетевые соединения и процессы оно создаёт. А мониторинг репозиториев позволяет заметить, что у важной библиотеки сменился владелец или перед релизом появились странные крупные коммиты.

Если беда уже случилась, действуйте по плану. Сначала изолируйте подозрительный пакет: остановите автообновления, зафиксируйте конфигурацию, проанализируйте масштаб влияния. Затем заблокируйте скомпрометированную версию, чтобы она не попала в новые сборки, и исключите её из используемых компонентов. После этого откатитесь на предыдущую версию — убедившись, что она чистая. На будущее: если пакет критически важен, сделайте форк и сопровождайте его самостоятельно. Либо полностью замените на более надёжный аналог.

В долгосрочной перспективе стоит внедрять принципы zero trust для зависимостей: не доверяйте компоненту только потому, что он популярен. Регулярно проводите аудит зависимостей, удаляйте неиспользуемые библиотеки, фиксируйте версии через lock-файлы и изолируйте сборочные среды. Тогда protestware не застанет вас врасплох.

А как в вашей команде устроен процесс проверки open-source компонентов? Используете ли вы SCA-инструменты, песочницы или полагаетесь на удачу? Поделитесь опытом в комментариях — это важная тема, и обсуждение поможет всем нам сделать свои поставки безопаснее.

Телеграм: t.me/ainewsline

Источник: vk.com

Комментарии: