Когда поддержка со стороны поставщика имеет значение: как ИИ меняет подход к безопасности открытого исходного кода

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

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

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

ИИ превратил ручеек в поток

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

Райан Морган, руководитель отдела исследований и разработок Spring в Broadcom, отмечает, что в отрасли произошел фундаментальный сдвиг.

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

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

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

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

Майкл Минелла, директор по исследованиям и разработкам Open Source Spring в Broadcom, наблюдал за тем, как этот сдвиг происходил внутри портфеля Spring. Раньше команда получала около семи отчетов о безопасности в месяц. Как только на сцену вышли передовые модели ИИ, эти цифры резко выросли.

«В марте мы получили 55 отчетов от сообщества, - говорит Минелла. - В апреле их число выросло до 112. Именно в апреле мы наконец получили доступ к этим передовым моделям и начали проводить внутреннее сканирование, в результате чего получили ещё 370 внутренних отчетов».

Это не просто дополнительная нагрузка для разработчиков; это заставляет команды переосмыслить подход к сортировке, проверке и выпуску программного обеспечения.

Поиск ошибок больше не является самой сложной частью

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

«Мы также заметили, что [ИИ] пока не идеален в том, что касается автоматического установления патчей или создания исправлений за вас», - говорит Морган, добавляя, что Broadcom по-прежнему полагается на опытных инженеров, которые пишут и проверяют каждый патч безопасности Spring перед выпуском.

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

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

Почему поддержка со стороны разработчика имеет преимущество

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

«Мы являемся авторитетным источником информации в отношении уязвимостей безопасности», - говорит Минелла.

«Мы являемся авторитетным источником информации в отношении уязвимостей безопасности», - говорит Минелла. «Если исследователь в области безопасности изучает Spring и обнаруживает уязвимость, он сообщает об этом именно команде Spring в Broadcom».

Это даёт разработчикам из самой компании значительное преимущество. «Мы создаём исправление в закрытом режиме. Мы работаем с ними… до того, как об этом узнают другие», - добавил Минелла. «У всех остальных сторонних разработчиков отсчёт времени на выпуск исправления начинается тогда, когда мы уже объявили, что устранили проблему».

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

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

Идти в ногу с ландшафтом угроз

Объем результатов, генерируемых искусственным интеллектом, также заставил разработчиков переосмыслить свои собственные процессы разработки.

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

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

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

«В мире, где уязвимости эксплуатируются менее чем за сутки, двухнедельный цикл выпуска устарел».

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

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

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

Открытый исходный код не исчерпал себя

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

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

Поскольку ИИ ускоряет обнаружение уязвимостей, предприятиям нужны исправления, которые были бы не только быстрыми, но и точными, протестированными и не способными вывести из строя производственные системы.

«Я действительно считаю, что уже сегодня мы видим: от поставщиков коммерческого программного обеспечения с открытым исходным кодом будут ожидать, что они будут тратить время и ресурсы на сканирование своего собственного программного обеспечения», - говорит Морган.

Разработка под руководством сообщества никуда не денется, но требования, предъявляемые к людям, поддерживающим критически важные проекты с открытым исходным кодом, быстро меняются.

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