В 2026 году резко возросло число атак на цепочки поставок программного обеспечения

При поддержке Chainguard

Злоумышленники всё чаще переносят свои усилия на более ранние этапы разработки, нацеливаясь на системы, которые создают и распространяют код, а не на сами конечные приложения. CI/CD-пайплайны, реестры пакетов, включая npm и PyPI, рабочие процессы GitHub Actions и инструменты для работы с ИИ-агентами — все они оказались взаимосвязаны и привлекают к себе столько же внимания, сколько раньше привлекало только производственное ПО. Противники захватывают широко используемые пакеты с открытым исходным кодом практически каждую неделю, и всего один взлом может затронуть десятки тысяч организаций вниз по цепочке поставок.

Атаки на цепочки поставок программного обеспечения начали стремительно набирать обороты в начале 2026 года, отмечает Куинси Кастро (Quincy Castro), директор по информационной безопасности (CISO) в Chainguard.

«Раньше атаки на цепочки поставок считались чем-то редким и экзотичным, как правило, очень целенаправленными и методичными, и специалисты по защите видели в них прежде всего инструмент уровня национальных государств для проникновения в труднодоступные места», — говорит Кастро. — «То что мы наблюдаем в этом году, — это злоумышленники, движимые финансовой выгодой, которые поняли, что разработка ПО — это ахиллесова пята организаций. По мере того как мы стали лучше защищать традиционные конечные точки и облачные среды, мы естественным образом вытеснили противников в гораздо менее защищенную область».

Атаки на цепочки поставок ПО напоминают кампании с использованием «watering hole» (водпопой) десятилетней давности, когда злоумышленники взламывали веб-сайты с целью атаковать беспечных посетителей. Эта динамика «один ко многим» играет на руку злоумышленникам и в атаках на цепочки поставок: взлом всего одного проекта с открытым исходным кодом дает потенциальный шанс скомпрометировать каждый проект, который его устанавливает. Это снижает маржинальные затраты на каждого нового пострадавшего практически до нуля, позволяя организатору атаки самостоятельно выбирать, какие именно зараженные среды преследовать дальше.

CI/CD-пайплайны и сборочные серверы остаются беззащитными

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

«У вас может быть пайплайн, глядя на который вы думаете: «Я отлично справляюсь с безопасностью: я сканирую код, блокирую критические уязвимости на этапе CI» и так далее», — говорит Кастро. — «Но затем вы отдаляете масштаб и видите, что эта сборочная система находится в общедоступном интернете, потому что команда разработчиков распределена по всему миру, а в скриптах сборки разрешено использовать долгоживущие персональные токены доступа. Это не защищенная система».

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

«Если вы посмотрите на большинство традиционных команд безопасности, в них обычно работает мало специалистов (или вообще ни одного) с реальным опытом DevOps или SRE», — добавляет Кастро. — «Их часто просят отслеживать и защищать системы, которые они никогда не использовали и не понимают, при этом им не хватает доверия со стороны коллег-инженеров, которые боятся, что служба безопасности что-нибудь сломает».

Масштабы бизнеса усложняют стандартизацию, особенно в компаниях, которые росли за счет поглощений и наследуют новый стек инструментов с каждой сделкой. Кастро, ранее занимавший должности CISO в двух крупных транснациональных компаниях, отмечает, что разработчики в компаниях любого масштаба находятся под постоянным давлением необходимости быстро выпускать релизы, и далеко не у всех есть необходимая поддержка или экспертиза для безопасной работы.

«Разработчики вынуждены делать то, что облегчает им работу», — говорит Кастро. — «Если им нужен конкретный GitHub Action, они просто берут его и запускают, рассчитывая на то, что служба безопасности делает всё необходимое для их защиты, хотя во многих случаях на практике этого не происходит».

ИИ-агенты для написания кода и «гражданские разработчики» расширяют поверхность атаки

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

Большая часть такой работы происходит на ноутбуках и связана с загрузкой пакетов из открытого интернета, где отсутствуют барьеры для внедрения средств контроля безопасности. Существующих мер защиты, управляемых ИТ-отделом, уже недостаточно, считает Кастро.

«Общаясь с людьми, пострадавшими от наплыва атак на цепочки поставок в этом году, мы выяснили, что зачастую единственным рубежом обороны у них были традиционные средства защиты конечных точек (EDR) и антивирусы», — поясняет он. — «Команды оперативной безопасности в этих компаниях выбивались из сил, реагируя на сообщения о том, что вредоносное ПО или червь установили себя в систему, или постоянно сканировали инфраструктуру в поисках следов заражения инженеров. Здесь говорит во мне CISO: как бы красиво ни звучали слова вроде «AI-native» (созданные для ИИ), нет ничего общего с искусственным интеллектом в том, чтобы позволять кому угодно делать что угодно, оставляя службу безопасности разбираться с последствиями».

Безопасность цепочки поставок должна опережать реагирование на инциденты

Ущерб от компрометации цепочки поставок может пережить само реагирование. Такие атаки часто похищают секретные данные из скомпрометированных сред, предоставляя злоумышленникам учетные данные, которые можно использовать спустя долгое время после обнаружения первоначального взлома.

В ходе мартовской атаки 2026 года на Trivy, широко используемый инструмент для сканирования уязвимостей с открытым исходным кодом, злоумышленники похитили облачные ключи, SSH-ключи, токены Kubernetes, пароли от баз данных и многое другое, потенциально подвергнув риску более 2500 организаций. Компания Aqua Security обновила учетные данные после обнаружения раннего взлома, но сдерживание оказалось неполным: у злоумышленников остался доступ, который помог осуществить последующую атаку на цепочку поставок.

«Людям нужен принципиально иной подход к безопасности цепочки поставок, ориентированный на предотвращение угроз по меньшей мере так же сильно, как на их обнаружение и реагирование», — говорит Кастро. — «Цель должна заключаться в том, чтобы изначально не допускать скомпрометированные пакеты в среду».

Проверенное происхождение переносит принятие решений на ранние этапы

«Мы вступаем в эпоху безграничного объема кода с открытым исходным кодом, и это никуда не денется», — говорит Кастро. — «При этом объемы кода и рост популярности vibe coding (разработки на базе промптов) приводят к тому, что агенты и менее квалифицированные пользователи сталкиваются с вредоносными пакетами-двойниками и атаками типа typo-squatting».

Чтобы в таких объемах отличать безопасное от небезопасного, требуются доказательства, привязанные к конкретному артефакту. Это превращает подтвержденное происхождение (provenance), подписанные артефакты и доверенные сборочные системы в инструмент контроля, который пайплайн применяет самостоятельно на машинно-ориентированной скорости.

«Вам нужно убедиться, что то, что вы подтягиваете в свой сборочный пайплайн, в точности является тем, чем должно быть — не просто полагаясь на чье-то слово, а имея возможность доказать это криптографически», — отмечает он. — «Кроме того, вам нужно знать, что код был собран в защищенной среде и в него ничего не внесли в самый последний момент».

Среда разработки становится средством контроля безопасности

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

«Это означает, что инструменты настраиваются с использованием репозиториев артефактов, правильных CI/CD-инструментов, защищенных экшенов, раннеров, навыков и изначально безопасных компонентов», — говорит Кастро. — «Злоумышленник, возможно, и сможет натворить каких-то бед, но ему придется приложить гораздо больше усилий, а тем временем вы предоставите защитникам массу преимуществ».

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

«Тем CISO, которые стремятся выделиться и зарекомендовать себя как драйверы бизнеса, проактивное создание такой среды в партнерстве с разработчиками и SRE поможет сделать компанию устойчивой к угрозам в сфере цепочек поставок ПО и безопасности приложений», — говорит Кастро. — «Это также способ для организаций стимулировать инновации, цифровую трансформацию и внедрение ИИ, не теряя контроля над цепочкой поставок программного обеспечения».

Спонсорские статьи — это контент, подготовленный компанией, которая либо оплачивает публикацию, либо имеет деловые отношения с VentureBeat, и такие материалы всегда четко маркируются. Для получения дополнительной информации обращайтесь по адресу sales@venturebeat.com.