Останніми місяцями ми дивувалися якості створених комп’ютером облич, фотографій котів, відео, есе та навіть мистецтва. Штучний інтелект (AI) і машинне навчання (ML) також тихо прослизнули в розробку програмного забезпечення з такими інструментами, як GitHub Copilot, Tabnine, Polycode, та інші логічним наступним кроком є розміщення наявної функції автозаповнення коду на стероїдах ШІ. Проте, на відміну від зображень котів, походження, якість і безпека коду програми можуть мати широкомасштабні наслідки — і принаймні для безпеки дослідження показують, що ризик реальний.
попередній наукові дослідження вже показав, що GitHub Copilot часто генерує код із уразливими місцями безпеки. Нещодавно практичний аналіз інженера безпеки Invicti Кадіра Арслана показав це пропозиції небезпечного коду все ще є правилом, а не винятком із Copilot. Арслан виявив, що пропозиції для багатьох поширених завдань включають лише абсолютні «голі кістки», часто використовуючи найпростіший і найменш безпечний шлях, і що їх прийняття без змін може призвести до функціональних, але вразливих програм.
Інструмент на кшталт Copilot — це (за задумом) автозавершення, підняте на новий рівень, навчене на відкритому вихідному коді, щоб пропонувати фрагменти, які можуть бути релевантними в подібному контексті. Це робить якість і безпеку пропозицій тісно пов’язаними з якістю і безпекою навчального набору. Тож важливіші запитання стосуються не Copilot чи будь-якого іншого конкретного інструменту, а взагалі програмного коду, згенерованого ШІ.
Розумно припустити, що Copilot — це лише вістря списа, і що подібні генератори стануть звичайним явищем у найближчі роки. Це означає, що ми, технологічна індустрія, маємо почати запитувати, як такий код генерується, як він використовується та хто візьме на себе відповідальність, якщо щось піде не так.
Сатнав синдром
Традиційне автозавершення коду, яке шукає визначення функцій для завершення імен функцій і нагадує вам, які аргументи вам потрібні, значно економить час. Оскільки ці пропозиції є лише швидким способом самостійного пошуку документів, ми навчилися беззастережно довіряти всьому, що пропонує IDE. Щойно з’являється інструмент на основі штучного інтелекту, його пропозиції більше не є правильними, але вони все одно виглядають дружніми та заслуговують довіри, тому їх, швидше за все, приймуть.
Особливо для менш досвідчених розробників зручність отримання безкоштовного блоку коду заохочує змінити мислення з «Чи достатньо цей код близький до того, що я б написав» на «Як я можу налаштувати цей код, щоб він працював для мене».
GitHub дуже чітко стверджує, що пропозиції Copilot завжди слід ретельно аналізувати, переглядати та тестувати, але людська природа диктує, що навіть нерівний код іноді потрапляє у виробництво. Це схоже на те, щоб керувати автомобілем, дивлячись більше на GPS, ніж на дорогу.
Проблеми безпеки ланцюга поставок
Команда Криза безпеки Log4j нещодавно привернув увагу до безпеки ланцюга поставок програмного забезпечення, зокрема безпеки з відкритим кодом Меморандум Білого дому на безпечну розробку програмного забезпечення та нов законопроект про підвищення безпеки відкритого коду. Завдяки цим та іншим ініціативам наявність будь-якого коду з відкритим вихідним кодом у ваших програмах незабаром може знадобитися вписати до списку матеріалів програмного забезпечення (SBOM), що можливо лише за умови свідомого включення певної залежності. Інструменти аналізу складу програмного забезпечення (SCA) також покладаються на ці знання для виявлення та позначення застарілих або вразливих компонентів з відкритим кодом.
Але що, якщо ваша програма містить згенерований ШІ код, який, зрештою, походить із навчального набору з відкритим кодом? Теоретично, якщо хоча б одна суттєва пропозиція ідентична існуючому коду та прийнята як є, ви могли б мати відкритий код у своєму програмному забезпеченні, але не у своєму SBOM. Це може призвести до проблем із відповідністю, не кажучи вже про можливість відповідальності, якщо код виявиться небезпечним і призведе до порушення — і SCA вам не допоможе, оскільки він може знаходити лише вразливі залежності, а не вразливості у вашому власному коді. .
Підводні камені ліцензування та атрибуції
Продовжуючи цей хід думок, щоб використовувати відкритий вихідний код, вам потрібно дотримуватися його умов ліцензування. Залежно від конкретної ліцензії з відкритим вихідним кодом, вам потрібно буде принаймні надати посилання на джерело або іноді випустити свій власний код як відкритий код. Деякі ліцензії взагалі забороняють комерційне використання. Незалежно від ліцензії, вам потрібно знати, звідки взявся код і як він ліцензований.
Знову ж таки, що, якщо у вашій програмі є згенерований штучним інтелектом код, який ідентичний існуючому відкритому коду? Якби у вас був аудит, чи виявилося б, що ви використовуєте код без необхідного посилання? Або, можливо, вам потрібно відкрити вихідний код деякого комерційного коду, щоб залишатися сумісним? Можливо, це поки що нереалістичний ризик із наявними інструментами, але це питання, які ми всі маємо ставити сьогодні, а не через 10 років. (Щоб було зрозуміло, GitHub Copilot дійсно має додатковий фільтр для блокування пропозицій, які відповідають існуючому коду, щоб мінімізувати ризики ланцюжка поставок.)
Глибші наслідки безпеки
Повертаючись до безпеки, модель AI/ML настільки ж хороша (і настільки ж погана), як і її набір для навчання. Ми бачили це в минулому - наприклад, у випадках алгоритми розпізнавання облич, що показують расові упередження через дані, на яких їх навчали. Отже, якщо у нас є дослідження, яке показує, що генератор коду часто створює пропозиції без урахування безпеки, ми можемо зробити висновок, що саме таким був його навчальний набір (тобто загальнодоступний код). А що, якщо незахищений код, згенерований штучним інтелектом, потім повертається до цієї кодової бази? Чи можуть пропозиції бути безпечними?
На цьому питання безпеки не закінчуються. Якщо генератори коду на основі штучного інтелекту набудуть популярності та почнуть складати значну частку нового коду, цілком імовірно, хтось спробує їх атакувати. Вже зараз можна обдурити розпізнавання зображень ШІ, отруївши його навчальний набір. Рано чи пізно зловмисники намагатимуться помістити унікальний уразливий код у загальнодоступні сховища в надії, що він з’явиться в пропозиціях і зрештою потрапить у робочу програму, відкриваючи її для легкої атаки.
А як щодо монокультури? Якщо кілька додатків використовують ту саму дуже вразливу пропозицію, незалежно від її походження, ми можемо розглядати епідемію вразливості або, можливо, навіть специфічну вразливість ШІ.
Слідкуйте за ШІ
Деякі з цих сценаріїв сьогодні можуть здатися надуманими, але ми в індустрії технологій повинні обговорити всі ці речі. Знову ж таки, GitHub Copilot знаходиться в центрі уваги лише тому, що наразі він лідирує, а GitHub надає чіткі попередження щодо застережень пропозицій, створених ШІ. Як і у випадку з автозаповненням у вашому телефоні чи пропозиціями маршрутів у вашій супутниковій навігації, це лише підказки, які полегшать наше життя, і ми самі вирішуємо прийняти їх чи залишити.
Завдяки потенціалу експоненціального підвищення ефективності розробки генератори коду на основі ШІ, ймовірно, стануть постійною частиною світу програмного забезпечення. Однак з точки зору безпеки додатків, це ще одне джерело потенційно вразливого коду, який має пройти суворе тестування на безпеку, перш ніж його буде допущено до виробництва. Ми шукаємо абсолютно новий спосіб вставити вразливості (і потенційно неперевірені залежності) безпосередньо у ваш основний код, тому має сенс розглядати кодові бази, доповнені штучним інтелектом, як ненадійні, доки не перевірять, а це означає тестувати все так часто, як ви може.
Навіть відносно прозорі рішення ML, такі як Copilot, уже викликають деякі юридичні та етичні питання, не кажучи вже про проблеми безпеки. Але уявіть собі, що одного разу якийсь новий інструмент почне генерувати код, який ідеально працює та проходить тести безпеки, за винятком однієї крихітної деталі: ніхто не знає, як це працює. Саме тоді настав час панікувати.
