ИИ-галлюцинации в отчётах об уязвимостях SQLite: 54 из 55 оказались ложными

JFrog проверила 55 ИИ-сгенерированных отчётов об уязвимостях SQLite. 54 из них не подтвердились в кодовой базе, то есть ошибочными оказались примерно 98% проверенных материалов. В отчётах встречались несуществующие функции и файлы, неверные ссылки на код и нерабочие эксплойты.

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

Среди ошибочных материалов были отчёты с критической маркировкой и высокими оценками риска. Если принять такой документ без ручной проверки, команда начнёт тратить время на несуществующую угрозу, а неподтверждённая запись может попасть в базу уязвимостей. История SQLite показывает границу применения ИИ в security: модель может предложить гипотезу, но доказательством её результат не становится.

JFrog проверила 55 отчётов об уязвимостях SQLite, 54 не подтвердились

Что именно считали ложным срабатыванием

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

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

Почему цифра 54 из 55 важнее единичного примера

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

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

Как выглядели ИИ-галлюцинации в отчётах SQLite

Галлюцинация модели в security-отчёте выглядит убедительно, пока читатель не сверяет её опорные детали с проектом. Текст может содержать название компонента, ссылку на файл, объяснение причины и код эксплойта. Ошибка обнаруживается в момент, когда эти элементы сопоставляют с актуальной версией SQLite.

Несуществующие функции и файлы

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

Проверка начинается с простого вопроса: есть ли названный объект в той версии SQLite, которую анализировал автор отчёта? Нужно зафиксировать состояние исходников и сверить имена, связанные вызовы и соседние участки. Если базовая сущность вымышлена, дальнейшее описание уязвимости теряет опору.

Неверные ссылки на код

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

Отдельная проблема, версия исходников. Код SQLite меняется, поэтому ссылка без номера версии или другого точного указателя может относиться к иному состоянию проекта. Аналитик сверяет путь, функцию, участок выполнения и условия, при которых возникает предполагаемая ошибка.

Нерабочий эксплойт как проверка реальности

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

Проверяют все звенья сценария: условия запуска, формат входных данных, нужную конфигурацию, фактическую реакцию программы и повторяемость результата. Безопасный тест проводят в изолированной среде. Наличие кода эксплойта в документе не равно подтверждению уязвимости.

Почему ошибочные CVE и высокие оценки риска особенно опасны

Высокий балл не заменяет техническое доказательство

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

Корректный порядок выглядит так:

1. найти компонент, функцию или участок, о котором говорит отчёт;
2. проверить связь между этим кодом и предполагаемым небезопасным поведением;
3. воспроизвести заявленный сценарий в контролируемой среде;
4. оценить последствия и присвоить приоритет подтверждённой проблеме.

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

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

Как ложная критическая находка меняет решения команды

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

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

Как ложные срабатывания загрязняют базы уязвимостей

Что происходит с разработчиками

Разработчику нужен проверяемый указатель: версия SQLite, путь к файлу, функция, условие входа и ожидаемый результат. Общего описания вроде критическая ошибка в обработке данных недостаточно. Если указанный объект вымышлен, специалист сначала ищет его, сверяет ветки и проверяет контекст, хотя устранять в коде нечего.

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

Что происходит с security-командами и базами данных

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

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

Проблема напоминает и о другом классе ошибок ИИ-агентов: широкие права и отсутствие подтверждения опасного действия могут привести к потере данных. В разборе инцидента с удалением около 700 ГБ показано, почему контроль человека и изоляция среды нужны даже при добросовестной задаче. Для отчётов об уязвимостях изоляция снижает риск, а независимая проверка защищает качество данных.

Как проверять ИИ-сгенерированный отчёт об уязвимости

Проверка не требует принимать на веру весь текст или сразу отвергать его целиком. Удобнее разбирать отчёт по опорным деталям и сохранять подтверждения каждого шага. Подходы к поиску и проверке ИИ-находок, включая работу с изолированной средой и историей кода, мы объясняли в материале о Google Mantis.

Шаг 1. Сверить сущности с реальным исходным кодом

Зафиксируйте версию SQLite, ветку или снимок исходников, который относится к отчёту. Затем найдите названные файлы, функции, структуры и связанные вызовы. Если хотя бы одна ключевая сущность отсутствует, отметьте это как отдельную причину для остановки проверки и уточнения.

• сверьте название проекта и версию;
• проверьте путь к каждому файлу;
• найдите функцию и её реальные вызовы;
• сохраните точный указатель на проверенный участок.

Шаг 2. Проверить логику уязвимости и ссылку на код

Найденного имени недостаточно. Проследите поток выполнения: какие входные данные получает функция, какие проверки проходят данные, какое состояние возникает после обработки и совпадает ли оно с описанным в отчёте воздействием.

Сверьте ссылку с контекстом. Указанный участок может быть безопасным сам по себе, а проблема, по версии модели, возникает в другом месте. Проверьте, относится ли фрагмент к нужной версии SQLite и не смешаны ли части разных веток.

Шаг 3. Проверить эксплойт и получить независимое подтверждение

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

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

Что этот случай говорит о применении ИИ в кибербезопасности

ИИ, источник гипотез, а не готовая запись в базе

Результат JFrog не отменяет пользу ИИ в security. Модель может помочь составить список подозрительных участков, предложить вопросы к коду, объяснить сложный фрагмент или подготовить черновик отчёта. Это экономит время на старте анализа.

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

Какие вопросы нужно задать перед доверием отчёту

• Существует ли указанная функция, файл или компонент в нужной версии кодовой базы SQLite?
• Ведёт ли ссылка на код к тому фрагменту, который выполняет описанную роль?
• Совпадают ли входные условия, поток выполнения и заявленное воздействие?
• Воспроизводится ли эксплойт в изолированной среде без доступа к рабочим данным?
• Проверил ли результат независимый специалист?

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

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