В мире открытого кода термин protestware стал новым классом риска в цепочке поставки ПО: мейнтейнеры намеренно вносят изменения, чтобы выразить личную позицию или отношение к происходящим событиям, что иногда может нарушить работу критически важных приложений или стать юридическим риском для разработчика или компании.
Опираясь на международные исследования и собственный анализ базы протестных пакетов, мы в CodeScoring попытались понять – остаётся ли protestware временной реакцией на кризисы или превращается в устойчивый элемент экосистем. В этой статье я, Артем Максимов, продуктовый аналитик, и Артем Иванов, дата-инженер, поделимся итогами наших исследований.
Этот материал будет полезен разработчикам, техлидам и AppSec/DevSecOps-инженерам, которые отвечают за выбор, обновление и контроль open source зависимостей, а также за оценку рисков, не сводящихся к классическим CVE.
Что такое protestware?
Protestware – пакеты открытого ПО, авторы которых намеренно вносят компрометирующие конструкции, чтобы выразить несогласие с политическими, социальными или экономическими событиями. В отличие от классического malware, protestware исходит не от внешнего злоумышленника, а от самого мейнтейнера, что усложняет обнаружение и оценку намерений. Чаще всего цель – привлечь внимание, реже – внесение недекларированных возможностей в код проекта, которые могут носить вредоносный характер.
От студенческих протестов до глобальных саботажей
История protestware тянется с 1960-х: тогда американские студенты вписывали протестные послания в перфокарты. В современном open source феномен начал набирать силу в 2010-х. Вот ключевые моменты:
2016: left-pad — разработчик удалил библиотеку из NPM после конфликта с компанией Kik из-за прав на имя пакета. Итог: массовый сбой в проектах вроде Babel и React. Хотя это не был осознанный политический протест, инцидент стал первым тревожным сигналом о хрупкости экосистемы.
2022: colors.js и faker.js — мейнтейнер сломал свои библиотеки, вставив зацикливания и удалив код. Это был вызов против эксплуатации труда мейнтейнеров. Тысячи приложений пострадали, но многие продолжили использовать эти пакеты.
2022: node-ipc – автор добавил код для удаления файлов по IP. Это затронуло фреймворк Vue.js и даже работу некоторых банков. Аналогичные случаи произошли с библиотеками sweetalert2 и es5-ext.
2023: e2eakarev – пакет изначально был нацелен на поддержку протеста в Палестине: при установке в Израиле пакет отображает политическое уведомление на английском языке.
2026: jqwik – мейнтейнер тестового фреймворка добавил в вывод тестов скрытую инструкцию для ИИ-агентов, призывающую удалить тесты и код jqwik, выражая несогласие с использованием генеративного ИИ для написания кода.
С 2022-го случаи участились из-за глобальных конфликтов: пакеты выводят мирные призывы, иногда с гео-дискриминацией. Такие всплески часто привязаны к кризисам, но данные фиксируют общий рост: от редких инцидентов в 2010-х к настоящим волнам в 2020-х.
Типы protestware в open source
Protestware бывает разным по степени вреда и проявлению в ПО – специалисты выделяют разный набор категорий в зависимости от методики. Например, исследователи из университета Аризоны составили следующую классификацию:
Аналитики CodeScoring выделяют несколько видов часто встречающихся протестов. Одни пакеты ограничиваются обычными сообщениями в README или описании. В большинстве случаев они безопасны, но могут намекать на поддержку определённых идей или призывать к действиям – например, в некоторых языках такие сообщения могут попадать в итоговую сборку продукта.
Другой популярный вариант – вывод логов в консоли при установке или запуске. Часто с проверкой геолокации по таймзоне и призывами – например, в пакете es5-ext советуют скачать Tor для борьбы с цензурой. Сообщения также могут выходить за пределы консоли: создавать всплывающие окна, перенаправления или файлы на устройстве, где устанавливается пакет, как в event-source-polyfill или peacenotwar.
Наибольшую опасность представляют пакеты, которые стремятся изменить или удалить файлы, вызвать зацикливание процессов или утечки данных. Известный случай – это node-ipc, пытавшийся стереть данные на машинах в определенных регионах.
Эти категории показывают, что граница между выражением позиции и саботажем становится всё тоньше. При этом даже мягкие формы могут эскалировать, если мейнтейнер решит усилить воздействие. Поэтому сканирование зависимостей должно учитывать не только уязвимости, но и любое нежелательное поведение.
Влияние на экосистемы
Влияние protestware не ограничено индивидуальными скачиваниями: оно бьет по цепочкам зависимостей. Как пример можно рассмотреть рост использования protestware в JavaScript библиотеках со временем. Специалисты из Университета Аризоны отмечают в своей статье: несмотря на протестный код, 10 из 12 анализируемых пакетов стали использоваться даже чаще – количество зависящих от них компонентов выросло. Некоторые из них до сих пор активно устанавливаются, собирая миллионы загрузок еженедельно. При этом частое упоминание в СМИ в результате протеста становится одним из факторов популярности компонента.
И сами разработчики действительно не желают бросать такие пакеты. В кейсе colors.js из 146 использующих данный пакет репозиториев только 15% отказались от зависимости – против 82% в случае скомпрометированного ua-parser-js. Почему? Протест часто не критичен, а замена – хлопотна.
Кроме того, многие мейнтейнеры воспринимают такие случаи не как угрозу, а как “социальный шум” – нечто, что можно просто переждать до следующего обновления. Это подтверждается через анализ обсуждений в соцсетях – 77% постов про es5-ext были посвящены выражению мнения о протесте, нежели технической составляющей. В итоге протестный код продолжает жить в сборке продукта, становясь частью повседневного технического ландшафта, а не исключением из него.
Устойчивый след протестного кода
Вопреки популярному мнению, protestware не ушло из open source после 2022 года: к 2025-му количество выявленных версий снизилось на 32.8%, но всё ещё держится на уровне 2.6 тыс. публикаций в год.
Исследование CodeScoring также показывает лидеров по инцидентам из более 400 затронутых пакетов:
Лидируют npm и PyPI – это объясняется не только числом пакетов, но и низким порогом публикации, что облегчает распространение протестного кода. Интересно, что на третьем месте Packagist: в PHP-экосистеме зависимостей меньше, но отдельные библиотеки имеют широкую распространённость и влияют на большое число downstream-проектов. В итоге риск сосредоточен: наибольшая часть случаев в двух-трех экосистемах, где даже единичный саботаж отзывается эхом во многих проектах.
Многие ли из них вернулись к исходному состоянию? Большинство – нет. Данные из базы знаний CodeScoring показывают следующую картину:
88.8% протестных изменений не откатываются – код остается в репозиториях и без внешнего давления не исчезает. Только 5.5% мейнтейнеров убирают изменения по той или иной причине, а 5.7% затронутых пакетов изначально создавались как инструменты протеста. Это подчеркивает: риски не самоустраняются, они требуют активного мониторинга.
Как отреагировало сообщество?
Реакция крупных игроков разделилась: некоторые поддерживают "свободу выражения", другие видят угрозу нейтральности. Open Source Initiative (OSI) прямо заявляет: protestware вредит, нарушая доверие и прозрачность. Разработчики решений анализа безопасности начали интегрировать проверку protestware в свои инструменты, отмечая отдельные пакеты как вредоносные или имеющие незадекларированную функциональность.
Параллельно идут дебаты об этичности таких мер, включающие как утверждения об ответственности перед конечным пользователем, так и признание проблем эксплуатации мейнтейнеров.
Эксперты корпоративного сектора уже воспринимают protestware как прикладную задачу безопасности, а как не разовую аномалию.
«Хотя пик медийного интереса к protestware прошел, для корпоративного сегмента это абсолютно реальный и труднопрогнозируемый риск в цепочке поставок ПО. Любое умышленное внедрение недекларированных возможностей превращает безобидную библиотеку в неконтролируемый элемент инфраструктуры. Это полноценный вектор угрозы, который требует такого же системного контроля и мониторинга, как и классические уязвимости».
Максим Щедрин, начальник управления тестирования безопасности «Т1 Иннотех»
Что делать?
Поскольку протестное ПО становится повторяющимся риском с реальными последствиями для компаний, защита от него должна быть частью стандартных DevSecOps-практик.
Прежде всего стоит проверять пакеты до загрузки во внутренний репозиторий и применять политики безопасности, которые учитывают не только известные уязвимости, но и признаки нежелательного поведения. Dependabot и похожие инструменты остаются полезными для регулярного обновления зависимостей, но сами по себе не решают задачу обнаружения protestware. Для полноценной защиты в долгосрочной перспективе необходим контроль цепочки поставки ПО на протяжении всего жизненного цикла – от входной проверки компонентов до постоянного анализа состава проекта.
Следующим шагом является построение инвентаря и анализ зависимостей: проверьте, является ли пакет прямым или транзитивным, и в каком окружении он используется. Это поможет приоритизировать риски. Далее фиксируйте версии ключевых библиотек и мониторьте обновления в реальном времени, чтобы быстро реагировать на подозрительные изменения.
Весь этот процесс поддерживается практикой композиционного анализа, которая позволяет отслеживать состав проекта, понимать, где используется спорный компонент, и оценивать изменения в зависимостях. При этом в случае protestware важно не ограничиваться классическими сигнатурами уязвимостей: по исследованию CodeScoring, из более чем 400 пакетов с признаками protestware только 3 получили идентификаторы CVE. Это означает, что такие риски не попадут в стандартный поток обработки угроз и могут остаться незамеченными для инструментов, ориентированных только на обновление уязвимых версий.