Фальшиві CVE, звіти, згенеровані ШІ, та потреба в перевірці

Створювати переконливі звіти про вразливості стає дешевше, що посилює негативні наслідки для супровідників програмного забезпечення та команд безпеки. У липні 2026 року для SQLite опублікували шість записів про загальні вразливості та експозиції (CVE), і два з них отримали оцінку критичності 9,8. Звіти здавалися достовірними: у них описували помилки безпеки пам’яті, наводили технічні пояснення та код для підтвердження концепції експлойту.

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

Проблема не обмежується SQLite. Торік Daniel Stenberg, супровідник curl, оцінив, що приблизно 20% отриманих звітів про безпеку були результатом ШІ-сміття. Орган, що присвоює номери CVE (CNA) у GitHub, отримав майже 4 000 запитів на присвоєння CVE у травні 2026 року — приблизно вдесятеро більше, ніж роком раніше. GitHub не пов’язував це зростання зі ШІ й не повідомляв про зниження якості поданих заявок, але стрімке збільшення їхньої кількості свідчить про надмірне навантаження на процес розкриття вразливостей.

ШІ спрощує створення докладних заяв про вразливості, але з’ясувати, чи вони достовірні, потребує чимало часу. І щойно запис CVE потрапляє до стрічок безпеки та загальнодоступних баз даних, виправлення початкового запису не означає автоматичного виправлення кожної його копії. Через це дедалі важливіше розрізняти повідомлену вразливість і ту, що пройшла технічну перевірку.

Що таке «фальшива» CVE?

Люди часто вживають термін «фальшива CVE», коли хочуть наголосити, що про вразливість, найімовірніше, повідомили помилково. Але «фальшива» не означає навмисно оманлива. Причиною може бути статичний аналіз, який не виявив перевірку даних або помилково визначив, що зловмисник може контролювати вхідні дані. У звіті може йтися про реальну функцію, але описуватися неможливий шлях атаки. Ідентифікатор (CVE ID) можуть присвоїти, а згодом відкликати, якщо зазначена умова насправді не є вразливістю. Це не те саме, що свідомо вигаданий звіт.

Суперечка також не означає, що CVE фальшива. Постачальник може не погоджуватися з висновками дослідника щодо можливості експлуатації, меж загрози або того, чи призначена функція для обробки недовірених даних. Але сама незгода не доводить, що дослідник помилився. І відхилення CVE не обов’язково означає, що її вигадали: запис можуть відхилити як дублікат або з адміністративних причин. Хоча ідентифікатор CVE не є незалежним технічним підтвердженням, галузь має серйозно ставитися до реальних повідомлень.

Чому фальшиві CVE — це проблема

Одна з проблем, яку ми спостерігаємо, — використання ШІ для створення звітів про вразливості без належної перевірки висновків. У таких звітах можуть бути докладні технічні пояснення, посилання на код і навіть PoC, через що вони здаються достовірними. Однак, як показав приклад із CVE для SQLite, деяких згаданих функцій не було навіть в уражених версіях.

GitHub повідомив про значне збільшення кількості поданих повідомлень про вразливості у 2026 році, хоча й не пов’язував це зростання зі ШІ та не заявляв про погіршення якості заявок. Побоювання полягає в тому, що зі збільшенням кількості звітів зростає і обсяг роботи, необхідної для їхнього розгляду, незалежно від того, чи підтверджуються наведені в них висновки.

Ті, кому доводилося проводити первинне сортування звітів про вразливості, легко зрозуміють, у чому полягає практична складність. Модель ШІ може виявити підозрілий виклик API, накидати сценарій експлойту й швидко створити професійно оформлений звіт. Щоб з’ясувати, чи здійсненний такий сценарій, може знадобитися перевірити точний випуск, простежити потік керування, розібратися, як дані потрапляють до функції, налаштувати тестове середовище й запустити ймовірний експлойт. Цей процес однаковий, незалежно від точності звіту, і може бути дорогим.

Фальшиві CVE можуть завдати й репутаційної шкоди. Повідомлення про вразливість може швидко поширитися стрічками сканерів, базами даних безпеки та результатами пошуку. Однак подальше виправлення може не набути такого самого розголосу. Навіть після того, як звіт оскаржили або відхилили, постачальникам доводиться виправдовуватися перед клієнтами, які бачили початкове повідомлення.

Також є ризик, що справжні вразливості залишаться непоміченими або їх усунення затягнеться, оскільки команди витрачають час на розгляд помилкових повідомлень. Коли ресурси супровідників і команд безпеки обмежені, кожна година, витрачена на спростування хибного спрацювання, — це час, який можна було б присвятити розслідуванню реальної проблеми безпеки.

Автоматизація як засіб протидії

Багато фахівців і досі вручну проводять первинне сортування, намагаючись упоратися з новим потоком звітів, але такий підхід несталий. Автоматизація виявляється надзвичайно корисною для перевірки заяв про вразливості з урахуванням фактично ураженого випуску й конфігурації. Ось п’ять запитань, які варто поставити:

• Чи правдоподібні передумови атаки, зокрема вимоги до конфігурації та дозволів?
• Чи існує згадана функція в ураженій версії?
• Чи може зловмисник дістатися до вразливого коду? Визначте, чи може відповідний код виконуватися за умов, на які поширюється вразливість, і чи може зловмисник передати дані, які до нього дійдуть.
• Чи можуть тестувальники відтворити цю поведінку в контрольованому тесті або за допомогою PoC?
• Чи свідчить спостережувана поведінка про вплив на безпеку, описаний у бюлетені?

Агентні інструменти можуть створювати тестові середовища, аналізувати шляхи виконання коду, генерувати PoC і фіксувати докази виконання для подальшого аналізу. Вони не можуть автоматично перевірити кожне твердження. Навіть якщо вразливість справжня, PoC може не спрацювати через неповноту середовища або неправильно задану умову запуску. Тестувальники можуть відтворити збій, не довівши заявленої можливості експлуатації. Саме через ці застереження людське судження залишається вкрай важливим. Однак такі інструменти допомагають командам наблизитися до відповіді, яку можна відтворити, перш ніж звіт забере ще більше часу в інженерії, управлінні вразливостями та службі підтримки клієнтів.

Як подолати перевантаження в екосистемі CVE

Жодна лаконічна політика не здатна чарівним чином розв’язати проблему фальшивих CVE. Однак допомогли б суворіші вимоги до доказів, які додають до заявок, і чіткіше зазначення статусу відтворення. Також було б корисно чіткіше врегулювати роботу зі спірними записами та швидше виправляти похідні дані. Дослідників слід заохочувати перевіряти результати, отримані за допомогою ШІ, перш ніж подавати їх.

Команди безпеки та постачальники мають зосередитися на перевірці доказів. Критична оцінка CVE не показує, чи можна дістатися до вразливого шляху у їхньому середовищі. Якщо PoC не спрацьовує, це ще не означає, що все гаразд. А отримання ідентифікатора CVE не звільняє команди від необхідної технічної роботи, щоб зрозуміти проблему.

ШІ розширює можливості виявлення вразливостей, а також дає змогу створювати переконливі на вигляд, але хибні твердження. У світі, де звітів стає дедалі більше, організаціям потрібно інвестувати в перевірку. Вона передбачає створення тестів, відтворення результатів, перевірку припущень і спрощення оцінювання доказів. Важливу роль у цій сфері може відіграти агентне тестування безпеки.