Резкий всплеск вредоносного кода в open source: компании тонут в рисках цепочки поставок ПО
За последние два года экосистема открытого ПО столкнулась с качественно новым уровнем угроз. По данным экспертов компании "Информзащита", количество вредоносных программ в open source‑пакетах выросло почти в 12 раз. Наиболее тревожный факт - более 80% всех зафиксированных случаев пришлись на начало 2026 года, то есть речь идет не о постепенном тренде, а о мощном скачке активности злоумышленников.
При этом уже свыше половины компаний признают, что сталкивались с подозрительными либо подтвержденными вредоносными сторонними пакетами в собственных цепочках поставки программного обеспечения. То есть проблема перестала быть теоретической: компрометация компонентов из открытых репозиториев становится для бизнеса повседневной реальностью.
Почему open source превратился в удобную площадку для атак
Ключевая причина - трансформация самой модели разработки. Современное корпоративное приложение на 70-90% состоит из готовых компонентов с открытым исходным кодом. В каждом продукте - десятки прямых зависимостей и сотни транзитивных, которые "подтягиваются" автоматически. В итоге формируется сложная, разветвленная и слабо контролируемая цепочка поставки, где любое звено может оказаться зараженным.
Этим активно пользуются атакующие. В 2025 году число атак через захват учетных записей разработчиков и мейнтейнеров пакетов выросло более чем в 12 раз по сравнению с предыдущим годом. После захвата аккаунта злоумышленники публикуют "обновление", которое внешне выглядит легитимным: корректное версионирование, привычное описание, знакомый репозиторий. Разработчики устанавливают его автоматически, не подозревая, что вместе с обновлением внедряют в инфраструктуру вредоносный код.
Новый вектор - атаки через ошибки ИИ‑ассистентов
Отдельной проблемой 2025 года стал slopsquatting. Суть схемы в том, что киберпреступники заранее регистрируют пакеты с названиями, которые искусственный интеллект способен "выдумать", отвечая на запросы разработчиков.
ИИ‑ассистент, генерируя пример кода или команду установки зависимости, "галлюцинирует" несуществующее имя библиотеки. Поскольку под этим именем в репозитории уже лежит подготовленный злоумышленниками пакет, разработчик, доверяя подсказке, устанавливает его как будто штатный инструмент. Для атакующих это крайне удобный канал проникновения: они получают прямой доступ в инфраструктуру через рекомендации, которым программисты привыкли верить.
Автообновления сокращают время реакции до часов
Ситуацию дополнительно обостряет подход к обновлению зависимостей. Около 60% команд разработки обновляют библиотеки минимум раз в неделю, нередко в полностью автоматическом режиме. В результате окно между моментом публикации вредоносного пакета и его проникновением во внутренний контур компании сокращается до нескольких часов.
При этом только 21% организаций сознательно вводят задержку перед установкой новых версий - технологическое "окно ожидания", позволяющее отследить первые сигналы о компрометации. Остальные забирают обновления практически в режиме реального времени, чем сильно упрощают задачу злоумышленникам.
Общую картину усугубляет то, что примерно четверть компаний не имеют единого централизованного механизма контроля за источниками библиотек и их обновлениями. Фактически каждая команда разработки самостоятельно решает, откуда и как подтягивать зависимости, что приводит к хаотичному, непрозрачному ландшафту компонентов.
Каким отраслям достается больше всего
По оценке "Информзащиты", наиболее сильно страдают отрасли с высокой скоростью разработки и большой долей внешнего кода в продуктах. На долю ИТ‑компаний и разработчиков программного обеспечения приходится около 28% всех выявленных инцидентов.
Финансовый сектор, традиционно являющийся приоритетной целью для атак, набирает 19%. Ритейл и e‑commerce формируют 17% случаев, что отражает возрастающую зависимость торговли от сложных цифровых платформ. На телекоммуникации приходится 12%, на энергетику и промышленность - 9%. Оставшиеся 15% распределяются между медиа, образованием и государственными структурами, которые также активно внедряют open source‑решения.
Особенно заметен дисбаланс для компаний с численностью до 500 сотрудников. При существенно меньшей доле на рынке им принадлежит около 22% всех инцидентов, связанных с использованием вредоносных пакетов. Основная причина - ограниченные ресурсы, отсутствие отлаженных процессов контроля и дефицит выделенных команд по безопасности приложений (AppSec).
"Внешние компоненты перестали быть просто удобным конструктором"
По словам Анатолия Песковского, руководителя направления анализа защищенности IZ:SOC компании "Информзащита", бизнес долгие годы относился к внешним библиотекам как к нейтральному "строительному материалу", который ускоряет разработку и снижает затраты. Риски рассматривались в первую очередь через призму уязвимостей в легитимном коде, для которых уже существуют привычные процедуры инвентаризации и обновления.
Но в случае с вредоносными пакетами, подчеркивает эксперт, логика меняется принципиально. Организация может получить активную угрозу в ту же секунду, когда разработчик подтянул новую версию зависимости. При этом формально пакет выглядит корректным: имеет проверяемую подпись, не содержит известных уязвимостей и проходит автоматические проверки. Опасность заключается именно в том, что вредоносная функциональность изначально заложена в сам дистрибутив.
Как перестроить работу с open source‑компонентами
Для снижения рисков недостаточно просто "строже проверять код". Эксперты настаивают на системной перестройке процессов работы с внешними библиотеками и фреймворками. В числе ключевых рекомендаций:
1. Жесткий контроль источников пакетов.
- Запрет прямых установок из публичных репозиториев с рабочих и серверных машин.
- Использование внутренних зеркал, репозиториев и прокси‑узлов, через которые проходят все загружаемые зависимости.
2. Фиксация версионности.
- Жесткое закрепление используемых версий библиотек в конфигурационных файлах.
- Отказ от "плавающих" зависимостей по принципу latest или неконтролируемых диапазонов версий.
3. Отмена неконтролируемых автообновлений.
- Запрет автоматического подтягивания новых релизов без предварительных проверок.
- Введение обязательных процедур тестирования и валидации безопасности перед выводом обновления в промышленную среду.
4. Технологическое окно ожидания.
- Осознанная задержка между публикацией новой версии в публичном репозитории и ее установкой внутри компании.
- Мониторинг новостей и отчетов по безопасности в этот период, чтобы успеть отреагировать, если пакет окажется скомпрометирован.
5. Постоянная инвентаризация зависимостей.
- Ведение актуального перечня всех компонентов, включая транзитивные.
- Привязка этого списка к процессам реагирования на инциденты, чтобы в любой момент понимать, в каких системах используется конкретный пакет и какие учетные данные он мог получить.
Роль AppSec и культуры безопасности в разработке
Одна из основных проблем - разрыв между командами разработки и службами информационной безопасности. Во многих организациях ответственность за выбор библиотек по факту лежит на разработчиках, в то время как безопасники подключаются уже постфактум, когда продукт почти готов.
Создание выделенных AppSec‑команд, которые встроены непосредственно в процессы DevOps, позволяет:
- вводить политики использования open source на уровне архитектуры;
- формировать белые и черные списки репозиториев и пакетов;
- проверять новые зависимости на стадии проектирования, а не перед релизом;
- обучать разработчиков типовым сценариям атак на цепочку поставок.
Культура безопасности должна стать частью инженерной практики: от ревью кода и образовательных программ до формальных требований в таск‑трекерах и пайплайнах CI/CD.
Что могут сделать небольшие компании с ограниченным бюджетом
Малым и средним организациям редко доступны дорогие специализированные платформы и большие штаты безопасников, однако базовый уровень защиты можно выстроить и с умеренными ресурсами. Практически применимые шаги:
- стандартизировать набор разрешенных репозиториев и библиотек;
- настроить хотя бы минимальный внутренний репозиторий, через который будут идти все установки;
- запретить разработчикам добавлять новые пакеты в продакшн без кросс‑проверки ответственным специалистом;
- использовать статический и составной анализ (Software Composition Analysis) в пайплайнах сборки;
- регулярно проводить экспресс‑аудит зависимостей и чистить неиспользуемые компоненты.
Даже эти относительно простые меры уже уменьшают поверхность атаки и усложняют жизнь злоумышленникам, ориентирующимся на массовые автоматизированные кампании.
Какую роль играет ИИ в усилении и в сдерживании угроз
Интересная особенность текущего этапа - ИИ одновременно усиливает и смягчает риски. С одной стороны, ошибки ИИ‑ассистентов, "придумывающих" несуществующие библиотеки, становятся прямым каналом для slopsquatting‑атак. С другой - те же технологии используются для автоматизированного анализа репозиториев, выявления подозрительных паттернов поведения пакетов и быстрого сопоставления цепочек зависимостей.
Компании, которые начинают применять ИИ‑инструменты не только для написания кода, но и для его проверки, получают конкурентное преимущество: вместо ручной проверки сотен пакетов они могут в автоматическом режиме отслеживать аномалии версий, подозрительные изменения и странные зависимости. Важное условие - не слепо доверять рекомендациям ИИ, а строить вокруг них проверяемые, формализованные процедуры.
Что будет дальше с безопасностью open source
С учетом текущей динамики можно ожидать, что атаки на цепочку поставок ПО станут одним из ключевых векторов киберугроз в ближайшие годы. Рост числа вредоносных пакетов в open source - не временный всплеск, а следствие зрелости экосистемы: туда, где сосредоточены основные ресурсы и зависимости бизнеса, закономерно приходят и злоумышленники.
В то же время у компаний есть реальный шанс снизить уязвимость, если воспринимать работу с внешним кодом как управляемый процесс, а не как "бесплатный конструктор". Централизованный контроль репозиториев, продуманная политика обновлений, постоянная инвентаризация и встроенные в разработку практики AppSec становятся не дополнительной опцией, а обязательным элементом архитектуры современных цифровых продуктов.
Те организации, которые выстроят эту систему раньше других, уменьшат вероятность критичных инцидентов и сократят стоимость реагирования, тогда как игнорирование проблемы open source‑цепочек будет все чаще оборачиваться масштабными простоями, утечками данных и прямыми финансовыми потерями.
