Лідери думок

ШІ може виявляти більше вразливостей, ніж будь-коли. Та вирішувати, що робити далі, усе ще мають люди.

mm
Додайте Unite.AI до бажаних джерел у Google

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

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

Нещодавні результати проєкту Project Glasswing — один із найяскравіших прикладів цього. За повідомленнями, Claude Mythos Preview виявила понад 26 000 потенційних вразливостей у різних програмних проєктах лише за кілька місяців. Однак, згідно з незалежним аналізом публічного реєстру розкриття вразливостей Glasswing, до процесу розкриття дійшли лише близько 10% цих знахідок, а виправлено зрештою було менш як 1%.

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

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

Виявлення вразливостей ніколи не було найскладнішим етапом

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

Ця відмінність важлива, адже виявлення вразливостей і їх усунення — принципово різні види діяльності.

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

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

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

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

Виклики проєктів із відкритим кодом

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

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

Коли система ШІ раптово виявляє сотні чи тисячі потенційних проблем у певній екосистемі проєктів, саме супровідники стають обмежувальним чинником.

Це не критика супровідників. Це відображення реальності.

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

Проблема полягає не лише в тому, щоб з’ясувати, чи існує вразливість. Проблема — в усьому, що відбувається після цього.

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

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

Підготовка до сплеску виявлення вразливостей за допомогою ШІ

То що мають робити підприємства? Насамперед організаціям потрібно усвідомити, що виявлення вразливостей за допомогою ШІ — це не проблема майбутнього. Це відбувається вже зараз. Проєкт Glasswing продемонстрував, що передові моделі здатні виявляти вразливості в масштабах, які ще кілька років тому було б важко уявити.

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

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

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

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

Адже найскладніше завдання у сфері кібербезпеки — не знайти вразливість, а визначити, що робити далі.

Аарон Мітчелл — генеральний директор HeroDevs, компанії, яка надає безстрокову підтримку програмного забезпечення з відкритим кодом, термін підтримки якого завершився. До призначення генеральним директором він обіймав посаду президента HeroDevs з 2021 до 2026 року. До приходу в HeroDevs Аарон заснував Freeplay, яку придбали у 2022 році, а також обіймав керівні посади у сфері продукту та стратегії в Nagarro, Domo, Ivanti та LANDESK.