Штучний інтелект: безпека програмного забезпечення – гонка, яку не можна програти

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

Ключові висновки:

• Ми довірили ШІ написання коду, втративши можливість перевіряти його перед запуском, але це лише половина проблеми.
• Інша половина полягає в тому, що поки ви намагаєтеся переглянути код, написаний вашим ШІ, його читає і ШІ конкурента, який працює швидше за вас.
• Протягом десятиліття ми гналися за одним показником (швидкістю випуску), а тепер ШІ надав його всім, включно з вашими потенційними нападниками. Тому швидкість більше не є перевагою.
• Рішення полягає в тому, щоб з тією ж швидкістю, з якою ви генеруєте програмне забезпечення, доводити, що воно відповідає вимогам бізнесу і витримає спроби зламу.

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

За даними компанії Anthropic, яка розкрила цю операцію в листопаді, ШІ самостійно виконав 80% до 90% роботи: знайшов слабкі місця, написав експлойти та витягнув дані — це було швидше, ніж будь-яка людська команда могла б зробити. Деякі з цих компаній були зламані, а ті, хто керував атакою, майже не витратили на це час.

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

Половина історії, яку я недооцінив

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

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

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

Швидкість повинна змінювати ваш підхід до інженерії. Компанія CrowdStrike виявила, що середній час, який потрібен зловмиснику для проникнення та початку руху в мережі, минулого року скоротився до 29 хвилин, а найшвидший випадок зайняв 27 секунд. В одному випадку дані почали виходити через чотири хвилини після того, як зловмисник отримав доступ. Атаки, пов’язані з противниками, керованими ШІ, зросли на 89% за один рік, а 42% використаних вразливостей були застосовані до того, як про них стало відомо (тобто, до того, як хтось міг написати патч). Як висловився Адам Майерс, керівник відділу контррозвідки в CrowdStrike: «Це гонка озброєнь у сфері ШІ».

Чому швидкість перестала бути вашою перевагою

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

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

Дослідники, які вивчали сотні мільйонів рядків робочого коду, виявили, що команди стали набагато частіше використовувати копіювання та вставку (copy-paste), ніж раніше, в міру поширення ШІ. Прибирання та рефакторинг, які підтримують кодову базу в здоровому стані, зменшилися за останні роки. Дослідження Google у сфері DevOps вказують на те саме: чим більше команда покладалася на ШІ, тим менш стабільними ставали їхні релізи. Зараз коду більше, і він “грубший”, ніж раніше. Тестування, створене для виявлення помилок, не встигає, тому більше з них потрапляє до клієнтів. Принцип «Випусти швидко, виправ пізніше» завжди передбачав, що ви повернетеся до виправлення. Тепер ви можете ніколи цього не зробити.

Відповідь — не новий інструмент тестування, і не лише перевірка, до якої я закликав. Це дисципліна: доводити, з тією ж швидкістю, з якою ви генеруєте програмне забезпечення, що те, що ви збираєтеся випустити, відповідає вимогам бізнесу і витримає спроби зламу. Дисципліна без назви не отримує бюджету, тому я дав їй ім’я. Я називаю це «Гарантія випуску, об’єднана ШІ» (AI-Unified Release Assurance) або AURA.

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

Що робити перед наступним релізом

Вам не потрібно нічого реорганізовувати, щоб почати. Вам потрібно взятися за три речі, які ви відкладали на потім.

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

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

По-третє, залишайте ім’я людини за кожним рішенням про випуск. Автоматизуйте роботу, а не відповідальність. Коли станеться злом, а для більшості компаній він станеться, «це зробив агент» — це не та відповідь, яку прийме ваша рада директорів або регулятор. Хтось має бути в змозі сказати, що було випущено, чому це було визнано безпечним і як ви дізнаєтеся, що це не так.

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

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

Ключові висновки

• Ми довірили ШІ написання коду, втративши можливість перевіряти його перед запуском, але це лише половина проблеми.
• Інша половина полягає в тому, що поки ви намагаєтеся переглянути код, написаний вашим ШІ, його читає і ШІ конкурента, який працює швидше за вас.
• Протягом десятиліття ми гналися за одним показником (швидкістю випуску), а тепер ШІ надав його всім, включно з вашими потенційними нападниками. Тому швидкість більше не є перевагою.
• Рішення полягає в тому, щоб з тією ж швидкістю, з якою ви генеруєте програмне забезпечення, доводити, що воно відповідає вимогам бізнесу і витримає спроби зламу.

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

За даними компанії Anthropic, яка розкрила цю операцію в листопаді, ШІ самостійно виконав 80% до 90% роботи: знайшов слабкі місця, написав експлойти та витягнув дані — це було швидше, ніж будь-яка людська команда могла б зробити. Деякі з цих компаній були зламані, а ті, хто керував атакою, майже не витратили на це час.

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

Принс Колі • Генеральний директор Sauce Labs

Учасник Entrepreneur Leadership Network®

Принс Колі є генеральним директором Sauce Labs, маючи майже 30-річний досвід створення корпоративних рішень на основі ШІ…

Подробиці можна знайти на сайті: www.entrepreneur.com