ИИ выявляет новые риски в цепочке поставок программного обеспечения

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

Значение модели Mythos от Anthropic заключается не столько в самой модели, сколько в более масштабных изменениях, которые она символизирует. Искусственный интеллект теперь способен автономно обнаруживать уязвимости в крупных кодовых базах, заставляя компании переосмыслить безопасность цепочки поставок программного обеспечения.

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

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

«Более 20 лет все наши методы работы с уязвимостями строились на предположении, об эксплуатация уязвимостей обходится дорого», — говорит Куинси Кастро (Quincy Castro), директор по информационной безопасности компании Chainguard. «ИИ полностью перевернул эту динамику. Мы приближаемся к миру, который вскоре будет затоплен новыми уязвимостями нулевого дня, а потенциально — и новыми классами уязвимостей, которые люди раньше не могли обнаружить. Уязвимости нулевого дня стали гораздо более массовым товаром».

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

Инструменты программирования на базе ИИ расширяют поверхность атак на цепочку поставок ПО

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

Новый класс уязвимостей в CI/CD-процессах, позволяющий злоумышленникам перехватывать рабочие процессы и компрометировать поставки ПО с открытым исходным кодом, получил кодовое название Cordyceps. Он может предоставить злоумышленникам полный контроль над репозиториями в десятках крупнейших организаций по всему миру, включая Microsoft, Google, Apache и Cloudflare.

Например, в Microsoft Azure Sentinel комментарий к запросу на слияние (pull request) мог запустить анонимный код злоумышленника в CI-системе Microsoft и похитить бессрочный ключ GitHub App. Запрос на слияние в репозитории набора инструментов разработки ИИ-агентов от Google («adk-samples») позволял выполнить код злоумышленника в CI-системе Google и получить полный контроль над репозиторием Google Cloud.

А в мае платформа кода с открытым исходным кодом GitHub объявила о том, что она подверглась хакерской атаке на цепочку поставок после того, как один из разработчиков GitHub установил зараженное расширение для VSCode. Хакеры, стоящие за взломом, — группировка под названием TeamPCP — утверждают, что получили доступ примерно к 4000 репозиториев кода GitHub. Среди других пострадавших — OpenAI и компания по заключению договоров на обработку данных Mercor. И только за последние несколько месяцев TeamPCP заявляет о проведении 20 волн атак на цепочки поставок, в ходе которых вредоносное ПО было скрыто более чем в 500 различных программных продуктах.

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

В то же время уязвимости, которые раньше могли оставаться незамеченными — будь то глубоко в стеке или считавшиеся недостаточно критичными для приоритетного внимания — теперь обнаруживаются в массовом масштабе. Вопрос о том, какие дефекты служба безопасности может позволить себе проигнорировать, выглядит иначе, когда ИИ может идентифицировать и потенциально объединить несколько проблем более низкого уровня в эффективный путь атаки. Цикл экстренного исправления, который раньше мог происходить раз или два в год, также начинает выглядеть совершенно иначе, когда критические уязвимости поступают целыми пачками.

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

Модели реактивной безопасности не успевают за эксплойтами на базе ИИ

Более глубокая проблема реактивной безопасности заключается в том, что она опирается на все более ошибочное представление о том, как на самом деле работают атаки. Графики установки патчей и сроки соблюдения нормативных требований предполагают, что вторжения ведут себя как события безопасности, т. е. стохастически предсказуемы и поддаются управлению посредством вероятностного принятия рисков.

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

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

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

Создание доверия на этапе разработки

Наиболее эффективный ответ требует смещения безопасности ближе к моменту создания программного обеспечения, а не упора преимущественно на обнаружение и реагирование, причем основой доверия должны служить происхождение ПО (provenance) и доверенные источники. Вместо того чтобы сканировать компоненты задним числом и управлять постоянно растущим бэклогом уязвимостей, цель состоит в том, чтобы начинать с программного обеспечения с открытым исходным кодом, собранного из проверенных источников, непрерывно обслуживаемого и избавленного от не верифицированных зависимостей.

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

«Ларри из финансового отдела не имеет за своей спиной команды SRE или специалистов по безопасности приложений», — говорит Кастро. «Он просто пытается делать свою работу. Единственный способ заставить это работать безопасно в компании, обрабатывающей медицинские карты или финансово чувствительные документы, — это если компоненты, которые он использует, по своей сути безопасны и надежны. Он не должен ничего об этом знать. Доверие должно быть заложено на более ранних этапах (upstream)».

Простота, а не большее число инструментов — решение проблемы рисков в цепочке поставок

Для предприятий, уже перегруженных программной сложностью, удвоение усилий с помощью существующих подходов — таких как инструменты анализа достижимости (reachability analysis), расширение команд AppSec, привлечение оффшорного персонала для обработки объема проблем — является проигрышной стратегией в условиях, когда передовые ИИ-модели будут становиться только мощнее.

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

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

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

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

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