Атаки через цепочки поставок выросли вдвое: облачная безопасность под давлением
Доля атак через цепочки поставок программного обеспечения выросла с 10% до 25%, так как хакеры заражают доверенные компоненты, а не ломают системы напрямую. Злоумышленники эксплуатируют уязвимости быстрее, чем компании успевают устанавливать патчи, что превращает один похищенный ключ в доступ к всей облачной инфраструктуре.
По данным компании «Информзащита», в первом полугодии 2026 года количество значимых киберинцидентов, связанных с облачной инфраструктурой, выросло на 58% по сравнению со второй половиной 2025 года. Показатель оказался почти вдвое выше уровня первого полугодия 2025-го.
Основная причина роста — не появление принципиально новых методов атаки, а ускорение развития уже известных техник. Злоумышленники быстрее перемещаются между связанными облачными сервисами, репозиториями кода и системами автоматизации сборки (CI/CD).
Угрозой стала не сама сложность атак, а их скорость: злоумышленники используют доверенные каналы распространения ПО, чтобы за короткое время получить доступ к множеству внутренних систем компании.
Атаки через цепочки поставок стали главным вектором
Доля инцидентов, связанных с компрометацией цепочек поставок программного обеспечения, выросла с 10% во второй половине 2025 года до 25% в первом полугодии 2026-го. Количество таких атак увеличилось более чем вдвое.
Механика атаки проста: хакеры не ломают инфраструктуру жертвы напрямую, а заражают доверенный компонент. Достаточно скомпрометировать аккаунт разработчика, плагин для среды разработки или элемент сборки. Вредоносный код попадает в системы клиентов через легальные каналы обновления пакетов.
Под удар попали популярные экосистемы:
- npm (пакеты JavaScript);
- PyPI (библиотеки Python);
- расширения VSCode;
- Jenkins и Composer.
В качестве примера приводится инцидент от 17 июня 2026 года, когда скомпрометированный аккаунт опубликовал вредоносные версии более чем 140 пакетов Mastra в npm. Дополнительный риск создает повторное использование похищенных секретов: до отзыва токены и ключи продолжают давать доступ к облачным средам.
Уязвимости эксплуатируются быстрее, а ИИ-инфраструктура уязвима
Количество новых раскрытий уязвимостей, требующих срочного внимания специалистов по безопасности, за первые шесть месяцев 2026 года удвоилось по сравнению с предыдущим периодом. Интервал между публикацией информации об уязвимости и ее применением в реальных атаках сокращается.
При этом доля инцидентов, связанных с прямым взломом интернет-доступных устройств, снизилась с 30% до 17%. Абсолютное число таких атак не уменьшилось значительно, но другие сценарии (цепочки поставок, кража учетных данных) росли быстрее.
Отдельным направлением риска стала инфраструктура для работы с искусственным интеллектом. Активность вокруг нее за полгода выросла примерно вдвое. Причин две:
- ИИ-шлюзы, MCP-серверы (Model Context Protocol — протокол взаимодействия моделей с инструментами) и агенты часто имеют доступ сразу к нескольким внутренним ресурсам и хранилищам секретов.
- Ошибка конфигурации одного компонента открывает путь к связанным системам.
Один из распространенных AI-шлюзов используется более чем в трети исследуемых облачных сред. За шесть месяцев он оказался связан с четырьмя различными проблемами безопасности, а более трети незащищенных MCP-серверов отдавали реальные данные без проверки учетных данных.
Что делать бизнесу: от инвентаризации до контроля ИИ
Эксперты рекомендуют пересмотреть подходы к защите облачных сред с учетом связей между компонентами. Ключевые меры включают:
- Инвентаризация и контроль доступов: Провести полный учет облачных учетных записей, сервисных аккаунтов, ролей IAM (Identity and Access Management — управление доступом), API-ключей и OAuth-токенов. Привилегии следует сократить до минимально необходимых, а долгоживущие секреты заменить короткоживущими токенами.
- Защита цепочки разработки: Проверять происхождение зависимостей, ограничивать права систем CI/CD и контролировать новые версии пакетов перед их внедрением. Необходимо отслеживать аномальные действия с репозиториями.
- Реакция на уязвимости: Для компонентов с подтвержденной активной эксплуатацией устанавливать исправления немедленно. Если это невозможно, в течение первых суток ограничивать внешнюю доступность или применять компенсирующие меры.
- Интеграция ИИ-инфраструктуры в контур безопасности: MCP-серверы, ИИ-агенты и сервисы моделей нельзя рассматривать как изолированный экспериментальный сегмент. Они должны проходить проверку аутентификации, сетевой доступности, прав и журналирования событий наравне с другими критичными приложениями.
Такой подход позволяет обнаруживать компрометацию до того, как один похищенный ключ или вредоносный пакет откроет доступ сразу к нескольким облачным средам и корпоративным данным.
Источник: infosec.ru