Фейковые cve и галлюцинации LLM в безопасности

Представь: приходит алерт о критической уязвимости в SQLite с оценкой 9.8 из 10, CISA подтверждает, Red Hat повышает приоритет — и только потом выясняется, что половина таких CVE может быть выдумкой.

Как появились эти cve

В GitHub появился репозиторий с серией уведомлений о критических уязвимостях, в основном в SQLite и других проектах. Формально всё выглядело убедительно: описание, CVSS-оценка, PoC и ссылки на версии. Но дальше включился стандартный конвейер: NVD помечает записи как критические, CISA ADP соглашается, вендоры поднимают приоритет, а сканеры зависимостей и тикет-системы начинают массово сигнализировать о проблеме.

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

Анатомия фейковой cve

Некоторые примеры особенно показательны. Один идентификатор описывает use-after-free в функции exprComputeOperands(), но эта функция отсутствовала в указанной версии SQLite. Другой заявляет, что исправление уже вошло в версию 3.51.3, хотя сравнение исходников 3.51.2 и 3.51.3 не показывает никаких изменений в нужном файле. Бывают и более грубые ошибки: ссылки на строки, которые указывают на комментарии или память, а не на код с уязвимостью, либо на номера строк, выходящие за пределы файла.

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

ЖИЗНЕННЫЙ ЦИКЛ ФЕЙКОВОЙ CVE
════════════════════════════
Создание            Проверка NVD          Распространение
┌─────────┐         ┌──────────────┐        ┌──────────────┐
│ GitHub  │──▶      │ Присвоение   │──▶     │ Сканеры,SLA  │
│ репо    │         │ CVSS 9.8     │        │ алерты       │
│ + LLM   │         │ CISA ADP     │        │              │
└─────────┘         └──────────────┘        └──────────────┘
     ▲                                            │
     │                                            ▼
     │              ┌──────────────┐        ┌──────────────┐
     └──────────    │ JFrog или    │◀──     │ Команда      │
     Исправление    │ другой       │        │ безопасности │
                    │ исследователь │        │ получает     │
                    │ находит      │        │ алерты       │
                    └──────────────┘        └──────────────┘

Почему это работает

Система CVE построена на доверии. Раньше глубокая проверка NVD сдерживала поток плохих заявок, но в 2024 году анализ был фактически приостановлен из-за бэклога. В результате фильтрация ослабла, а подача CVE стала слишком простой: не требуется работающий PoC, достаточно убедительного описания и корректно заполненной формы.

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

Чем это грозит индустрии

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

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

ЧЕКЛИСТ ПРОВЕРКИ CVE
═════════════════════
┌────────────────────────────────────────────────────────┐
│ 1. Есть ли CVE на официальной странице вендора?        │
│    └─ Нет → повышенный риск ложного срабатывания       │
│                                                        │
│ 2. Указан ли коммит или PR с исправлением?             │
│    └─ Нет → стоит проверить вручную                    │
│                                                        │
│ 3. Существует ли функция/номер строки в этой версии?   │
│    └─ Нет → это галлюцинация                           │
│                                                        │
│ 4. Совпадают ли версии в CPE с описанием?              │
│    └─ Противоречия → флаг на дополнительную проверку  │
│                                                        │
│ 5. Работает ли PoC в изолированной среде?              │
│    └─ Нет → повод усомниться                           │
└────────────────────────────────────────────────────────┘

Как отличить фейковую cve

Есть несколько красных флагов. Первый — отсутствие подтверждения от вендора: если уязвимость реальна, она обычно есть на официальной странице безопасности проекта. Второй — нет истории коммитов, хеша, PR или обсуждения в рассылке. Третий — противоречия в метаданных, например несовпадающие версии или пустые поля CPE. Четвёртый — невозможные ссылки на код: номера строк вне файла или функции, которых не было в указанной версии.

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

Практический вывод

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

Доверяй, но проверяй. Особенно когда оценка 9.8.

Ссылки

• SQLite Critical CVEs or LLM Slop? — первичный источник статьи
• Официальная страница CVE SQLite — эталон для проверки SQLite-уязвимостей