Новая карта угроз OSS: как Frontier LLMs меняют правила игры

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

Автор: Коби Шамама, директор по работе с клиентами в VMware Tanzu

Более половины компаний из списка Fortune 500 и немало корпоративных организаций в Израиле основывают ядро своего производства и приложений на проектах с открытым исходным кодом, таких как Spring, RabbitMQ и Bitnami. Как те, кто вносит вклад, разрабатывает и поддерживает эти проекты в VMware Tanzu, мы видим вблизи, как фокус безопасности открытого кода полностью изменился за последние месяцы. Причина проста: большие языковые модели вышли на поле, и они читают код лучше, чем все мы.

Передовые языковые модели (или Frontier LLMs) оказались отличными читателями кода. AI-сканирования сегодня обнаруживают уязвимые паттерны, которые люди упускали десятилетиями: во FreeBSD, операционной системе, считающейся одной из самых безопасных в мире, таким образом был обнаружен CVE, скрывавшийся в коде 20 лет. Mozilla выпустила 150 исправлений для более чем 270 уязвимостей, обнаруженных при AI-сканировании. И мир Spring также чувствует это: в марте 2026 года сообщество отправило 55 отчетов о безопасности, что в восемь раз больше исторического среднего показателя, а в апреле поступило 482 отчета, которые привели к 26 новым CVE.

Единственный показатель, который действительно интересует CISO

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

В 2020 году в среднем проходило более 700 дней с момента публикации уязвимости до ее фактического использования. В 2025 году это число сократилось до 44 дней, а сегодня, в 2026 году, почти 30% уязвимостей используются всего за 24 часа. Значение простое: вопрос уже не в том, сколько уязвимостей будет найдено, а в том, каков Mean Time To Remediate (MTTR) вашей организации. Как быстро исправление доходит до вас и как быстро вы способны внедрить его в продакшн, не сломав систему. Именно в этой точке проходит четкая граница между использованием общественного открытого кода и открытым кодом, подкрепленным ответственностью и SLA корпоративного поставщика.

3 стратегии исправления (Remediation), которые действительно работают

Так как же победить злоумышленников в гонке вооружений AI? Это зависит от проекта с открытым кодом, с которым вы работаете. Вот 3 наши стратегии, которые, как мы уже знаем, работают и защищают ваш код:

Spring — исправление в источнике. В ответ на волну отчетов команда Spring выпустила крупнейший раунд обновлений безопасности за 23 года существования проекта, и она сама запускает сканирования на основе frontier models, чтобы находить и проверять уязвимости раньше злоумышленников. Клиенты Tanzu Spring получают доступ Day Zero к CVE-only — включающий только исправления безопасности, без сюрпризов, еще до публичного раскрытия. Чтобы CVE не застрял у вас в пайплайне, Spring Application Advisor сканирует ваши приложения, отображает их состояние относительно актуальных версий и создает автоматические Pull Requests прямо в CI. Таким образом, обновление, которое заняло бы недели, превращается в текущий процесс.
Bitnami — знать, что попадает в производство. Bitnami — это проект, который полностью разрабатывается и поддерживается у нас. Принцип остается тем же уже много лет: каждый компонент строится из источника, в закрытой среде. Наши клиенты могут потреблять Helm charts, Images и OVA с минимумом уязвимостей.
RabbitMQ — тот, кто написал код, выпускает исправление. Message Broker является излюбленной целью злоумышленников: через него проходят токены, транзакции и конфиденциальная информация. Код RabbitMQ написан у нас, и наши клиенты продолжают получать CVEs Patches даже для версий, которые больше не поддерживаются в OSS (например, 3.13 покрыта до конца 2029 года). Это наряду с непрерывным сканированием кода при каждом commit и глобальной командой безопасности, доступной 24/7.

А что происходит у вас?

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

Есть ли у вас точная картина зависимостей, работающих в продакшене (актуальный SBOM, а не файл requirements годовой давности)?
Сколько времени проходит у вас с момента публикации CVE до того, как исправление заработает в продакшене?
Стоит ли за каждым компонентом открытого кода, который вы запускаете, сторона, выпускающая исправления, включая конкретную версию, на которой вы находитесь?

Передовые языковые модели превратили обнаружение уязвимостей и их использование в автоматический и быстрый процесс. Единственный способ сократить MTTR и оставаться стабильными перед лицом новых угроз — это бороться с автоматизацией с помощью автоматизации. Команда VMware Tanzu в Израиле сопровождает ведущие организации в защите ядра производства и приложений, предоставляя полную технологическую оболочку, жесткие SLA и доступ Day Zero к критическим исправлениям безопасности для Spring, Bitnami и RabbitMQ.

Хотите защитить свою среду OSS в эпоху AI? Свяжитесь с нами: [email protected]

Деятельность в сотрудничестве с C Data, официальным дистрибьютором VMware by Broadcom в Израиле.

Новая карта угроз OSS: как Frontier LLMs меняют правила игры