Количество вредоносных программ в open source увеличилось более чем в 10 раз

Анализ причин показывает, что ключевым фактором стала архитектура современной разработки, где доля open source компонентов в корпоративных приложениях достигает 70-90%. Каждое приложение включает десятки прямых зависимостей и сотни транзитивных, что формирует разветвленную и слабо контролируемую цепочку поставки. На этом фоне злоумышленники все чаще используют компрометацию учетных записей разработчиков и сопровождающих пакетов. В 2025 году число атак через захват аккаунтов выросло более чем в 12 раз год к году, а сами атаки маскируются под легитимные обновления. Отдельным вектором в 2025 году стал slopsquatting: злоумышленники заблаговременно регистрируют пакеты с именами, которые ИИ-ассистенты «галлюцинируя» в ответ на запросы разработчиков, – и те устанавливают вредоносный код, не подозревая об обмане. Дополнительное давление создает практика автоматического обновления библиотек: по оценкам, около 60% команд внедряют новые версии компонентов не реже одного раза в неделю, что сокращает окно между публикацией вредоносного кода и его попаданием в инфраструктуру до нескольких часов. При этом только 21% компаний применяют задержку перед установкой новых версий, несмотря на понимание риска. Ситуацию усугубляет ограниченная видимость цепочки зависимостей: около четверти организаций не имеют централизованного контроля за источниками и обновлениями библиотек.

Наиболее уязвимыми остаются отрасли с высокой скоростью разработки и значительной долей внешнего кода. По оценке экспертов «Информзащиты», на ИТ и разработку программного обеспечения приходится 28% выявленных инцидентов, финансовый сектор занимает 19%, ритейл и e-commerce – 17%, телеком – 12%, энергетика и промышленность – 9%. Остальные 15% распределяются между медиа, образованием и государственным сектором. Отдельно выделяются компании с численностью до 500 сотрудников: на них приходится около 22% всех случаев использования вредоносных пакетов при существенно меньшей доле в общем объеме рынка. Это связано с ограниченными ресурсами на выстраивание процессов контроля и отсутствием выделенных команд AppSec.

Снизить эти риски можно за счет последовательной перестройки процесса работы с внешними компонентами. Эксперты рекомендуют компаниям ввести обязательный контроль источников получения пакетов, использовать внутренние репозитории и прокси-узлы вместо прямой загрузки из публичных хранилищ, закреплять версии зависимостей и исключать бесконтрольные автоматические обновления. Для новых версий целесообразно устанавливать технологическое окно ожидания, чтобы не забирать пакет в инфраструктуру в первые часы или дни после публикации, когда вероятность скрытой компрометации максимальна. Не менее важно выстроить постоянную инвентаризацию состава программных компонентов, включая транзитивные зависимости, и увязать ее с процессами реагирования, чтобы служба безопасности понимала, где именно используется скомпрометированный пакет и какие учетные данные могли быть затронуты. Отдельного внимания требует защита рабочих мест разработчиков и сборочных контуров, поскольку именно они чаще всего становятся первой точкой соприкосновения с вредоносным кодом.