Поддельные CVE, отчёты, сгенерированные ИИ, и необходимость проверки

Создавать убедительные отчёты об уязвимостях становится дешевле, что повышает нагрузку на разработчиков программного обеспечения и команды безопасности. В июле 2026 года для SQLite опубликовали шесть записей об общих уязвимостях и рисках (CVE), две из которых получили оценку серьёзности 9,8. Отчёты выглядели правдоподобно: в них описывались ошибки, связанные с безопасностью работы с памятью, приводились технические пояснения и код для воспроизведения уязвимостей.

Однако исследователи JFrog выяснили, что некоторые функции, упомянутые в этих отчётах, отсутствовали в затронутых версиях. Более того, ни один из примеров кода для воспроизведения (PoC) не позволил подтвердить заявленные уязвимости. На странице SQLite, посвящённой CVE, сейчас говорится, что эти шесть сообщений не описывают ошибки; впоследствии записи CVE были отклонены.

Проблема не ограничивается SQLite. Дэниел Стенберг, сопровождающий curl, в прошлом году оценил, что примерно 20% поступавших сообщений об уязвимостях были результатом работы ИИ, производящего низкокачественный контент. В мае 2026 года подразделение GitHub, уполномоченное присваивать номера CVE (CNA), получило почти 4 000 запросов на присвоение CVE — примерно в 10 раз больше, чем годом ранее. GitHub не связал этот рост с ИИ и не отметил снижения качества сообщений, однако резкое увеличение их числа подчёркивает, насколько перегружен процесс раскрытия уязвимостей.

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

Что такое «поддельная» CVE?

Термин «поддельная CVE» часто используют, чтобы обозначить запись об уязвимости, которая, вероятно, была создана на основании ошибочного сообщения. Однако «поддельная» не значит намеренно вводящая в заблуждение. Причиной может быть статический анализ, который не учитывает проверку данных или ошибочно считает, что атакующий контролирует входные данные. В отчёте может быть описана реально существующая функция, но указан недопустимый путь атаки. Идентификатор (CVE ID) может быть присвоен, а затем отозван, если описанное условие на самом деле не представляет собой уязвимость. Это не то же самое, что заведомо вымышленный отчёт.

Спор вокруг уязвимости — тоже не поддельная CVE. Поставщик может оспаривать выводы исследователя о возможности эксплуатации, границах модели угроз или о том, предназначена ли функция для обработки недоверенных данных. Но сам факт спора не доказывает, что исследователь ошибся. И отклонение CVE не обязательно означает, что запись сфабрикована: её могут отклонить как дубликат или по административным причинам. Хотя наличие идентификатора CVE само по себе не является независимым техническим подтверждением, отрасли необходимо серьёзно относиться к достоверным сообщениям.

Чем опасны поддельные CVE

Одна из проблем, с которыми мы сталкиваемся, — использование ИИ для создания отчётов об уязвимостях без надлежащей проверки результатов. Такие отчёты могут содержать подробные технические пояснения, ссылки на код и даже примеры для воспроизведения уязвимости, из-за чего выглядят правдоподобно. Но, как показали CVE для SQLite, некоторые упомянутые функции вообще отсутствовали в затронутых версиях.

GitHub сообщил о значительном росте числа сообщений об уязвимостях в 2026 году, хотя не связывал этот рост с ИИ и не заявлял о снижении качества сообщений. Опасение заключается в том, что с увеличением числа сообщений растёт и объём работы по их проверке — независимо от того, подтвердятся ли указанные в них сведения.

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

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

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

Автоматизация в борьбе с проблемой

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

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

Агентные инструменты могут создавать тестовые среды, анализировать пути выполнения кода, генерировать PoC и фиксировать свидетельства выполнения для последующего изучения. Они не могут автоматически подтвердить или опровергнуть каждое утверждение. Даже если уязвимость подлинная, PoC может не сработать, если среда настроена не полностью или триггер выбран неверно. Специалисты могут воспроизвести сбой, не доказав заявленную возможность эксплуатации. Именно поэтому человеческая оценка по-прежнему крайне важна. Однако эти инструменты помогают командам быстрее получить воспроизводимый результат, прежде чем разбор отчета отнимет еще больше времени у специалистов по разработке, управлению уязвимостями и поддержке клиентов.

Как справиться с перегрузкой в экосистеме CVE

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

Команды по безопасности и поставщики должны сосредоточиться на проверке доказательств. Критическая оценка CVE не показывает, доступен ли уязвимый путь в их среде. Если PoC не срабатывает, это еще не значит, что все в порядке. Получение идентификатора CVE также не освобождает команды от необходимости провести техническую работу, требуемую для понимания проблемы.

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