Сегодня искусственный интеллект способен превратить патч безопасности в работающий эксплойт всего за несколько часов. В таких условиях ожидание планового «окна обслуживания», запланированного на следующую неделю, становится для бизнеса гораздо более серьезным риском, пишут на портале The New Stack Орен Пенсо, глобальный технический директор подразделения Tanzu компании Broadcom, и Майкл Коте, старший технический специалист VMware
Рассмотрим, как в 2026 г. развивается ситуация с уязвимостью в популярной Open Source-библиотеке. Мейнтейнер вносит исправление и публикует бюллетень безопасности. Спустя всего несколько часов кто-то направляет ИИ-модель на анализ различий (diff) между старой и новой версиями кода — и получает готовый эксплойт. На следующее утро ваш сканер обнаруживает CVE, создается заявка, а исправление планируется к внедрению в рамках «окна обслуживания» на следующей неделе. Но к тому моменту эксплойт уже вовсю используется злоумышленниками.
Еще год назад такой подход к управлению изменениями в корпоративной среде считался приемлемым, но сегодня он безнадежно устарел.
И на то есть веские причины. В своем отчете «Patchmageddon» («Патчмагеддон»), опубликованном в июле 2026 г. (в его подготовке участвовали руководители подразделений кибербезопасности J.P. Morgan Asset Management), председатель группы по рыночной и инвестиционной стратегии в подразделении J.P. Morgan Asset & Wealth Management Майкл Чембалест подробно описывает ситуацию. Модели вроде Mythos от Anthropic или GPT-5.5 от OpenAI теперь обнаруживают ранее неизвестные уязвимости в таких масштабах, которые недоступны ни одной команде исследователей-людей. Только за первый месяц работы проект Glasswing (инициатива Anthropic и партнеров) выявил более 10 000 новых уязвимостей нулевого дня высокого и критического уровней опасности.
Одновременно с этим сократилось время до начала эксплуатации уязвимости. Если в 2021 г. медианный интервал между раскрытием информации об уязвимости и ее первым использованием составлял около года, то в
Первый удар принимает на себя Open Source
Именно Open Source оказывается под основным давлением: во-первых, это фундамент для большинства современных программных продуктов, а во-вторых, его исходный код — как следует из названия — открыт для всех. Это просто замечательно — и именно так всё и должно быть, но это также означает, что для хакеров уязвимости в Open Source — самая лёгкая добыча.
Люди, на чьи плечи ложится борьба с этим потоком уязвимостей, раскрытых ИИ, — это, по большей части, волонтёры. К маю 2026 г. Anthropic сообщила Open Source-мейнтейнерам о 530 уязвимостях высокого и критического уровня, однако к тому моменту было устранено лишь 75 из них. Этим летом многие мейнтейнеры закрывали программы по поиску уязвимостей и фактически «уходили на покой», чтобы хоть немного передохнуть от колоссального напряжения.
Ваша новая стратегия безопасности
Нравится вам это или нет, но подход корпораций к безопасности обычно меняется, когда возникает острая необходимость — и, скажем прямо, лёгкое чувство тревоги. Вот ещё несколько поводов для беспокойства:
1. Модели становятся всё совершеннее. По прогнозам Чембалеста, возможности, которыми сегодня обладают лишь спецслужбы отдельных государств, в ближайшие
2. Скорее всего, вы уже используете уязвимый код. Большая часть того, что работает в ваших системах, была взята из публичных репозиториев месяцы, а то и годы назад. Согласно данным Datadog за февраль 2026 г., типичная зависимость отстаёт от своей последней мажорной версии в среднем на 278 дней. Это устаревший код, который ждёт своего часа, чтобы стать инструментом для атаки.
3. Критерии оценки изменились. Чембалест прямо заявляет: теперь организациям придётся оценивать себя не только по точности устранения уязвимостей, но и по скорости этого процесса. Если раньше нормой считался
Если вы владеете платформой, отвечаете за безопасность приложений или принимаете решения по технологическим рискам в регулируемой отрасли — эта проблема уже нависла над вами, независимо от того, предпринимаете вы какие-либо действия или нет. Суета без плана — это как сидеть в самолете, который задерживается на пять часов, рядом с пассажиром, который непрерывно переписывается в мессенджере, а каждое входящее сообщение сопровождается громким звуком, похожим на кряканье утки. Раздражает и напрочь убивает настроение.
Чтобы избавиться от этого «кряканья», давайте рассмотрим подход, которым Орен делится с руководителями в сфере платформ и безопасности в финансовом секторе.
Перестаньте строить свою стратегию безопасности в расчете на «бесплатное пиво»
Над Open Source-проектами работает недостаточно людей, чтобы оперативно выпускать исправления.
Чембалест уделяет особое внимание вопросу концентрации усилий вокруг отдельных мейнтейнеров. Согласно исследованию Linux Foundation и Гарвардского университета, охватывающему 50 крупнейших Open Source-проектов, в 23% из них более 80% добавленного кода — заслуга одного-единственного разработчика, а в 94% проектов более 90% кода написано менее чем десятью людьми. По данным компании Anchore, в реестре npm насчитывается более 18 млн. пакетов, у которых указан лишь один мейнтейнер.
Большинство сообществ, создающих и поддерживающих Open Source, делают всё, что в их силах, а многие при этом даже выгорели, пытаясь сделать еще больше. Но обещание «бесплатного» (в смысле «бесплатного пива») никогда не подразумевало, что вам гарантируют идеальную безопасность и мгновенное устранение уязвимостей в день их обнаружения. Обещали, по сути, только «бесплатное пиво». Корпорации десятилетиями пользовались этим «бесплатным пивом» — ПО с открытым кодом, — хотя им не раз намекали, что такой подход граничит с безответственностью. Теперь мы видим подтверждение этому, причем ситуация создана нами же. Пришло время заплатить за пиво.
Именно здесь на помощь приходит профессиональное открытое ПО. Да, это означает — вдохните глубже, закройте свои таблицы — что за использование ПО, которое можно свободно скачать, приходится платить.
За профессиональным Open Source стоит либо поставщик, который несет реальную ответственность за продукт, либо фонд, располагающий штатом специалистов по безопасности, финансируемыми мейнтейнерами и отлаженным процессом выпуска релизов, который не зависит от выгорания отдельных сотрудников. Команда, создавшая код и досконально его знающая, берет на себя исправление ошибок и работает в рамках соглашения об уровне обслуживания (SLA).
Техническое руководство J.P. Morgan в отчете, подготовленном Чембалестом, дает четкие рекомендации: используйте актуальные версии ПО и отказывайтесь от зависимостей, если вы не можете определить, кто их поддерживает, если за поддержкой стоит лишь один человек или если проект выглядит заброшенным. Если вы не знаете, кто отвечает за поддержку пакета, вы не можете рассчитывать на то, что кто-то исправит в нем уязвимости.
Установка патчей безопасности — залог непрерывности бизнеса
Эрик Скейлс, руководитель направления платформенной инженерии для Tanzu Platform в компании Charles Schwab, говорит прямо: «Если вам когда-нибудь приходилось устанавливать патчи на сервер, вы знаете: никто не хочет ничего обновлять. Никто вообще не хочет ничего трогать. Но теперь все боятся попасть в заголовки новостей — и в итоге лишиться работы».
Обычно установку патча откладывают, чтобы не прерывать бизнес-процессы. Поскольку обновление может что-то сломать, его переносят на следующее «окно обслуживания» — или даже дальше. В отчете J.P. Morgan приводится исследование, согласно которому более 80% специалистов по безопасности хотя бы раз откладывали установку патча, чтобы избежать сбоев в работе компании.
Когда до появления эксплойтов проходили месяцы, такой подход был оправдан. Теперь же, когда эксплойты появляются уже через день после раскрытия уязвимости, использование необновленной системы становится гораздо большей угрозой для непрерывности бизнеса.
Тем не менее, проблема возможных сбоев никуда не делась. Любое исправление, которое, помимо устранения риска, создает риск дополнительных перебоев в работе, скорее всего, будет отложено. А именно за такие отсрочки и приходится расплачиваться, когда на устранение уязвимости есть всего сутки. Злоумышленники как раз и рассчитывают на то, что вы будете медлить.
Сделайте так, чтобы правильный путь был самым простым
Контролируйте происхождение используемого вами Open Source — еще более строго, чем вы делаете это сейчас.
Давно прошли те времена, когда корпоративные разработчики могли скачивать из Интернета всё, что им вздумается, и сразу использовать это в работе. Потребовалось немало усилий, чтобы искоренить эту привычку. Сегодня большинство крупных компаний пропускают все загружаемые зависимости через внутренний прокси-сервер для артефактов — например, JFrog Artifactory или Sonatype Nexus. Разработчики настраивают свои системы сборки на этот прокси, а тот, в свою очередь, подтягивает компоненты из репозиториев вроде Maven Central, npm или PyPI. Заставлять разработчиков снова менять устоявшиеся рабочие процессы — идея не из лучших, да и удовольствия в этом мало.
К счастью, этого делать не нужно. Чтобы изменить источник, из которого поступает ПО с открытым исходным кодом, достаточно просто перенастроить прокси-сервер — больше ничего менять не придется. Если указать в качестве источника поддерживаемый сервис (например, TrueSource), то файлы сборки, URL-адреса и конвейеры останутся прежними. Разработчики даже не заметят разницы. Единственное отличие заключается в том, что библиотеки (например, Spring) теперь будут содержать исправления, которые зачастую появляются еще до того, как CVE станет публично известной.
Прокси-сервер может взять на себя часть задач по исправлению уязвимостей. Его можно настроить так, чтобы он блокировал версии с известными уязвимостями и автоматически подставлял вместо них ближайшие исправленные версии. В результате сборки продолжают работать, и никому не приходится создавать отдельные заявки на исправление. Исправленный пакет становится версией по умолчанию — разработчики получают его, даже не запрашивая специально.
Это критически важный момент для решения проблемы «патчмагеддона» (массового устранения уязвимостей). Менять привычки разработчиков, когда они уже устоялись, — задача непростая. Но поскольку можно просто перенаправить репозитории на другой прокси-сервер, менять привычки сотрудников не требуется.
Орен работал с командами, развивающими крупные платформы в сфере финансовых услуг, где зависимости уже проходят через подобные прокси-серверы. Для них задача не сводится к внедрению новой платформы для управления цепочкой поставок ПО во всей организации. Всё гораздо проще: нужно лишь указать прокси-серверу новый источник.
Именно поэтому мы утверждаем: единственное приемлемое изменение — это отсутствие видимых изменений.
Остальная часть плана
Описанные выше ключевые аспекты — зачастую самые сложные. Есть еще три момента, которые стоит учесть:
1. Измеряйте скорость доставки исправлений в производственную среду. Отслеживайте время, которое проходит с момента раскрытия информации об уязвимости до развертывания исправления — для 50 наиболее важных зависимостей. Именно по этому показателю, как отмечается в отчете J.P. Morgan, вас будут оценивать.
2. Выясните, кто отвечает за поддержку ваших критически важных зависимостей. Для каждой из них укажите организацию, которая занимается её сопровождением. Пакеты, поддерживаемые одним мейнтейнером, а также заброшенные проекты выделите в отдельный список.
3. Используйте ИИ для поиска уязвимостей и подготовки исправлений, а к процессу внесения изменений (слияния кода) привлекайте соответствующих специалистов — в идеале, самих мейнтейнеров этого кода.
Сегодня подход к безопасности кардинально меняется. Уделите этому должное внимание и скорректируйте стратегию безопасности вашей организации. Это особенно актуально, если вы — как и большинство крупных компаний, а в особенности финансовые организации — самостоятельно разрабатываете и эксплуатируете значительный объем ПО.
