Від ризику до відповідальності: Ахмад Шадид про створення безпечних робочих процесів з підтримкою ШІ

Коротко

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

Останні місяці «кодинг Vibe» — це робочий процес, орієнтований на ШІ, де розробники використовують великі мовні моделі (LLMs) та агентські інструменти для генерації та вдосконалення програмного забезпечення — набирає популярності. Водночас кілька галузевих звітів підкреслюють, що хоча код, створений ШІ, забезпечує швидкість і зручність, він часто вводить серйозні ризики безпеки та ланцюгів постачання.

Дослідження Veracode показало, що майже половина коду, створеного LLM, містить критичні вразливості, оскільки моделі ШІ часто генерують небезпечні реалізації та ігнорують проблеми, такі як ін’єкційні вразливості або слабка автентифікація, якщо їх явно не запитати. Недавнє академічне дослідження також зазначило, що модульні «навички» ШІ в системах на основі агентів можуть мати вразливості, які дозволяють підвищення привілеїв або розкриття ланцюгів постачання програмного забезпечення.

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

Що трапляється з чутливим корпоративним кодом у асистентах кодування ШІ і чому це ризиковано?

Більшість сучасних інструментів кодування можуть захищати дані лише до певного рівня. Корпоративний код зазвичай шифрується під час передачі на сервер провайдера, зазвичай через TLS. Але коли код потрапляє на ці сервери, він розшифровується в пам’яті, щоб модель могла його читати та обробляти. На цьому етапі чутливі деталі, такі як власна логіка, внутрішні API та деталі безпеки, відображаються у відкритому тексті в системі. І саме тут полягає ризик.

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

Чому ви вважаєте, що основні інструменти кодування ШІ є фундаментально небезпечними для корпоративної розробки?

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

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

Якщо провайдери не зберігають і не тренують на клієнтському коді, чому цього недостатньо, і які технічні гарантії потрібні?

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

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

Такі механізми мають бути базовою вимогою, оскільки вони перетворюють конфіденційність у вимірювану властивість, а не просто обіцянку.

Чи повністю вирішує запуск ШІ локально або у приватному хмарі ризики конфіденційності?

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

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

Що означає «конфіденційний ШІ» для інструментів кодування?

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

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

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

Які існують компроміси або обмеження використання конфіденційного ШІ наразі?

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

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

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

Чи очікуєте ви, що регулятори або стандарти незабаром вимагатимуть, щоб інструменти ШІ зберігали всі дані у зашифрованому вигляді під час обробки?

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

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

Як зараз виглядає «відповідальне кодинг Vibe» для розробників і ІТ-лідерів?

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

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

Дивлячись у майбутнє, як ви бачите еволюцію асистентів кодування ШІ з точки зору безпеки?

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

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