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

В то время как ИИ помогает опытным исследователям безопасности находить сложные уязвимости нулевого дня с беспрецедентной скоростью, он одновременно порождает поток низкокачественных отчетов об уязвимостях, созданных с помощью ИИ. Результатом стала разрозненная экосистема, которая с трудом держится на плаву. Соотношение полезного сигнала к шуму в данных об уязвимостях стремительно падает, мейнтейнеры open-source утопают в галлюцинирующих «slop», а фундаментальные институты, такие как Американская национальная база данных уязвимостей (NVD), сгибаются под тяжестью огромного объема поступающих заявок.

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

Всплеск CVE в цифрах

Команда исследователей безопасности JFrog собрала данные о CVE, опубликованных с 2021 года. Ниже представлен график, показывающий неуклонный рост объема CVE в последние годы.

Из-за ИИ объем CVE растет пугающими темпами

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

Этот всплеск привел к серьезным изменениям в том, как оцениваются CVE и каково качество этих оценок.

Мальчик, который кричал «Волки»

В январе 2026 года последствия этого растущего бремени проверки вылились в важную веху: Даниэль Стенберг, создатель широко используемой утилиты curl, объявил о закрытии программы выплаты вознаграждений за найденные ошибки проекта. По словам Стенберга, взрывной рост созданных ИИ заявок в 2025 году привел к потоку недействительных отчетов, а доля заявок, подтвержденных как уязвимости, упала ниже 5%.

Всего шесть месяцев спустя Майкл Катандзаро, бывший тогда координатором безопасности проекта GNOME, объявил об изменениях в системе отслеживания безопасности GNOME. Катандзаро заявил, что больше не будет пересылать отчеты о безопасности мейнтейнерам GNOME, которые явно отказались от получения контента, созданного ИИ. Поскольку подавляющее большинство поступающих отчетов в 2026 году использовали LLM, пояснил он, проект был вынужден работать в условиях предположения, что подавляющее большинство отчетов об уязвимостях теперь содержат материалы, созданные ИИ. Чтобы справиться с этой новой реальностью, Катандзаро также сократил срок раскрытия уязвимостей в GNOME с 90 до 30 дней для проблем, о которых сообщается 1 августа 2026 года или позже. Отметив, что некоторые другие проекты, в частности ядро Linux, внедрили политику немедленного полного раскрытия информации для отчетов, которые кажутся созданными с помощью ИИ, GNOME приняла сокращенное окно в качестве компромисса для ускорения процесса без чрезмерного давления на мейнтейнеров.

Изменение политики Национальной базы данных уязвимостей

Поток CVE также заставил NIST изменить подход к приоритизации анализа NVD. В объявлении о работе NVD от апреля 2026 года NIST заявил, что начиная с 15 апреля 2026 года он будет отдавать приоритет CVE из Каталога эксплуатируемых уязвимостей CISA, программного обеспечения, используемого федеральным правительством, и критически важного ПО. NIST также перенес накопленные CVE, опубликованные до 1 марта 2026 года, в категорию «Не запланировано». На наш взгляд, это оставляет многие опубликованные CVE без обогащения со стороны NVD и перекладывает большую часть бремени проверки на команды безопасности предприятий.

ИИ сокращает путь от раскрытия до эксплуатации

ИИ не только ускоряет обнаружение уязвимостей; он также сокращает время и объем экспертизы, необходимые для превращения информации об уязвимости в работающий эксплойт. В одном из случаев в мае 2026 года, связанном с CVE-2026-46529, который затрагивает просмотрщик документов Evince от GNOME и его форки, исследователь использовал Claude для разработки вредоносного эксплойта выполнения кода в один клик. Контролируемые исследования PoCGen и Anthropic продемонстрировали аналогичные возможности, показав, как злоумышленники могут использовать период между публичным раскрытием информации и массовым выпуском патчей.

Инфляция критичности

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

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

Годовое количество CVE, разделенных по степени критичности: «Критическая», «Высокая» и другие

Это различие заложено в самом CVSS. В official FIRST CVSS v4.0 User Guide указано, что базовые оценки CVSS предназначены для измерения степени тяжести уязвимости и не должны использоваться отдельно для оценки риска. Тем не менее сканеры, дашборды и политики исправления часто рассматривают базовую оценку как универсальный показатель срочности.

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

Цена оценки в больших масштабах

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

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

Диссонанс критичности: случай curl

Яркая иллюстрация инфляции критичности проявилась в недавнем четырехмесячном периоде, связанном с проектом libcurl. С июня мейнтейнеры опубликовали 27 CVE с оценкой воздействия на безопасность от низкой до средней. Однако, когда CISA оценила те же уязвимости, почти все они были повышены до высоких или критических оценок.

Когда команда исследователей безопасности JFrog изучила это поразительное несоответствие, мы обнаружили, что назначенное значение векторов CVSS не отражает реального технического состояния уязвимостей. Например, недостатки, получившие критические оценки, часто оказывались лишь сбоями на стороне клиента или требовали специфических конфигураций клиента, находящихся вне контроля злоумышленника. В ряде случаев ошибки use-after-free на стороне клиента ошибочно классифицировались как сетевые угрозы повреждения памяти, что приводило к критическому рейтингу, который, по нашей оценке, не отражал реальный вектор атаки и практическое влияние на безопасность.

Фейковые CVE: рост сгенерированного ИИ информационного мусора

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

Пример из практики: мусорные бюллетени SQLite

Ярким примером этого системного сбоя является исследование, опубликованное нами в JFrog в июле 2026 года и посвященное волне критических бюллетеней. В недавно созданном репозитории на GitHub было опубликовано более 50 бюллетеней безопасности — пакет отчетов, затрагивающих SQLite и различные другие проекты с открытым исходным кодом. Отчеты выглядели отшлифованными и авторитетными, в них подробно описывались сложные проблемы повреждения памяти Use After Free (UAF). Им быстро присвоили высокие оценки по шкале CVSS, вплоть до 9.8 (Critical), и программа ADP от CISA с этим согласилась.

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

Несуществующий код: в бюллетенях упоминались такие функции, как exprComputeOperands() и jsonBlobEdit(), которых не было в целевых версиях SQLite.
Невозможные номера строк: в одном бюллетене указывалось на уязвимость в строке 3555 в файле, содержащем всего 2706 строк.
Призрачные исправления: в другом утверждалось, что исправление было зафиксировано в более новом релизе, однако различия в исходном коде показали полное отсутствие изменений в упомянутых файлах.

Поскольку текущий конвейер CVE перегружен объемами и не требует работающего POC перед выставлением оценок, эти отчеты напрямую попадают в нисходящие потоки. Из 55 бюллетеней, опубликованных этой учетной записью, 54 были полностью сфабрикованы, однако подобные отчеты могут проникать в GHSA, корпоративные сканеры и оповещения разработчиков.

Цена поддержания актуальности

Когда прибывает лавина исправлений

Давление становится особенно заметным, когда поступает большое количество исправлений одновременно. По данным Oracle, ее July 2026 Critical Patch Update, крупнейший на сегодняшний день выпуск безопасности, устранил 1 434 уникальных CVE с помощью 1 449 патчей в 334 продуктах. Компания Oracle объяснила такие масштабы отчасти выявлением практически применимых результатов безопасности с помощью ИИ. Однако для клиентов получение большего количества исправлений не делает их развертывание проще. Каждой организации по-прежнему приходится выявлять затронутые системы, решать, что является наиболее срочным, тестировать соответствующие обновления и вписывать их в свой график релизов.

ИИ также обнаруживает ошибки, которые не удавалось обнаружить даже после многих лет традиционных исследований. Агент безопасности, разработанный depthfirst reported 21 zero-day vulnerabilities in FFmpeg, причем некоторые из них оставались в коде от 15 до 20 лет, несмотря на масштабное фаззинг-тестирование и ручной анализ.

Разрыв между обнаружением и устранением

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

CISA has connected this pressure directly to AI-assisted discovery, заявляя, что ИИ значительно увеличивает скорость обнаружения новых уязвимостей, в то время как защитники и так с трудом поспевают за ними. Согласно Отчету Verizon за 2026 год о расследовании утечек данных (Data Breach Investigations Report), на который ссылается CISA, организации полностью устранили только 26% уязвимостей из каталога известных эксплуатируемых уязвимостей (Known Exploited Vulnerabilities) в течение 2025 года по сравнению с 38% годом ранее, в то время как медианное время полного устранения выросло до 43 дней. Британский Национальный центр кибербезопасности выпустил аналогичное предупреждение, заявив, что обнаружение с помощью ИИ может породить волну патчей для уязвимостей с притоком обновлений всех уровней серьезности, которые организациям придется развертывать чаще и в больших масштабах. Вместе эти источники демонстрируют практический эффект возросшего объема: даже когда команды совершенствуют свои процессы, более длинная очередь все равно может заставить ждать исправления дольше.

Следите за новостями…

ИИ увеличил как скорость, так и неопределенность в экосистеме CVE. Поиск уязвимостей больше не является единственной задачей, поскольку проверка, приоритизация и исправление тех из них, которые представляют реальный риск, стали не менее важными. Во 2-й части этой серии, «Влияние эпохи ИИ на исследования CVE: СТРАТЕГИИ ЗАЩИТЫ», мы рекомендуем лучшие практики, демонстрируем цепочку эксплойтов libheif от JFrog с поддержкой ИИ и показываем, как JFrog Xray и JFrog Advanced Security помогают командам оценивать реальные риски.

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

Примечание. Содержимое этого блога предоставляется исключительно в общеинформационных и иллюстративных целях. Оно отражает информацию, доступную на дату публикации, указанную ниже, и может не обновляться. Примеры и результаты носят иллюстративный характер; фактические результаты могут отличаться в зависимости от вашей среды и сценария использования. JFrog не делает никаких заявлений и не дает гарантий относительно того, что контент является полным, точным, актуальным или подходящим для ваших конкретных обстоятельств. вы несете ответственность за оценку контента, прежде чем полагаться на него. Содержимое этого блога не изменяет какие-либо соглашения, регулирующие использование вами продуктов или услуг JFrog. Использование продуктов по-прежнему регулируется применимым Лицензионным соглашением JFrog (Subscription Agreement) или другим письменным соглашением между вами и JFrog.