Для безпеки ШІ потрібна друга думка

ШІ пише код швидше, ніж ми встигаємо його захищати. Чи вдається вам не відставати?

Поки ви дочитаєте це речення, розробники та їхні ШІ-агенти встигнуть внести близько двох тисяч комітів коду. Рік тому на цей час їх було б приблизно 150.

За минулий рік темпи створення програмного забезпечення за допомогою ШІ зросли до приголомшливого рівня. У вересні 2026 року GitHub зафіксував 7,38 мільярда комітів лише за один місяць — це більш ніж уп’ятеро перевищує загальну кількість за відповідний період роком раніше. Наслідки цього вибухового зростання для безпеки надзвичайно серйозні. Кожен із цих комітів містить код, який хтось має розуміти, супроводжувати й захищати. Cloud Security Alliance з’ясувала, що розробники, які використовують ШІ, у компаніях зі списку Fortune 50 вносять код у три-чотири рази частіше за своїх колег, а щомісячна кількість виявлених ними проблем безпеки зросла приблизно вдесятеро.

А тепер подумаймо, кому доводиться мати справу з цим зростанням. Команда CISO за чисельністю така сама, як і рік тому, але черга невиконаних завдань — ні. Повідомлень про вразливості стає більше, щомісяця виправлень меншає, а кількість невирішених критичних проблем зростає. Не дивно, що Gartner зазначає: вигорання CISO стає критичним операційним ризиком.

Спокуса обрати найновішу модель

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

Передові моделі ШІ чудово знаходять нові експлойти й не внесені до каталогів вади завдяки ймовірнісному аналізу. Але результати різняться. Якщо п’ять разів просканувати той самий код, результати збігатимуться лише приблизно в третині випадків, свідчить дослідження Checkmarx.

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

Це зовсім не аргумент проти ШІ. Це аргумент на користь другої думки щодо безпеки. Який би механізм ви не обрали, оцініть його за трьома критеріями.

Питання перше: достовірність

Якщо сканер повідомляє про проблему, чи варта вона вашого часу?

Достовірність — це основа довіри. Недостовірне повідомлення забирає в розробника цілий день і ще трохи підриває довіру до служби безпеки. У масштабі команди саме хибні спрацювання змушують людей перестати прислухатися. Сповіщення сприймають як «хлопчика, що кричав: “Вовк!”», і вони зливаються з фоновим шумом.

Саме тут важлива послідовність. Детермінований аналіз щоразу дає ту саму відповідь для того самого коду, що зміцнює довіру й дає змогу перевірити результати.

Питання друге: точність

Чи знаходите ви всі найважливіші проблеми?

Достовірність допомагає зрозуміти, чи варта уваги виявлена проблема, але не показує, що сканер пропустив. Ми використовуємо практичний показник, що походить із науки про дані, — F1. Він оцінює результативність за шкалою від 1 до 0 на основі двох чинників:

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

Сканер може здаватися точним, якщо позначає майже нічого, або ретельним, якщо позначає все, — але в обох випадках показник F1 буде низьким. Середнє значення в галузі становить близько 0,20. Ми наполегливо працювали над цією проблемою й отримали результати, точність яких у три-чотири рази перевищує точність стандартного сканера.

Вища точність спрощує розробникам усі подальші етапи роботи. Ваша команда витрачає менше часу на перевірку й більше — на виправлення проблем.

Питання третє: рентабельність інвестицій

Як максимально ефективно використати інвестиції та ресурси?

Це питання найчастіше оминають під час пілотного запуску, а в робочому середовищі відповідь на нього дається найболючіше.

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

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

Ми називаємо це податком на токени. Це як їздити по продукти на Ferrari: ви платите за потужність, яка для такої поїздки не потрібна. Жорстко закодовані облікові дані й ін’єкції SQL — це передбачувані шаблони, які детермінований аналіз надійно виявляє.

Безпека застосунків має розвиватися

Саме так побудовано архітектуру Checkmarx Fusion. Рушії на основі правил відтворювано встановлюють фактичну основу аналізу й потребують менше ресурсів, ніж аналіз на основі токенів. Найсучасніші моделі зосереджуються на тому, чого правила не можуть передбачити: нових шаблонах, складній логіці та можливості експлуатації в контексті. Потім рівень аналізу результатів об’єднує їх в один надійний набір.

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

Виявити проблеми — це лише початок. Та сама логіка стосується їх запобігання. Розгляньмо приклад. Якщо надати розробникам можливості безпосередньо під час створення коду — у середовищі IDE, де вони його пишуть, — ми зможемо запобігти проблемам ще до їх появи. Так само, коли вразливості все ж прослизають, чому б не надати розробникам виправлення, готові до злиття, для найважливіших із них? Саме ці проблеми ми й розв’язуємо, прагнучи поступово скоротити наявний backlog і якнайшвидше досягти результату з мінімальними зусиллями.

Код уже працює. Чи встигаєте ви за ним?

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

Тож не загубіться в цифрах. Поставте будь-якій програмі три запитання: чи можу я довіряти тому, що вона виявляє? Чи знаходить вона достатньо того, що має значення? Чи реально впровадити її в усій моїй організації? Поєднання детермінованої точності з аналітичними можливостями найсучасніших моделей дає найкращі шанси відповісти «так» на всі три запитання.

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