Представлено Chainguard
Важливість моделі Mythos від Anthropic полягає не стільки в самій моделі, скільки в ширшому зрушенні, яке вона уособлює. Штучний інтелект (ШІ) тепер здатний самостійно виявляти вразливості у великих кодових базах, змушуючи підприємства переосмислити безпеку ланцюжка постачання програмного забезпечення.
Команди безпеки стикаються з новою реальністю, коли ШІ може виявити вразливості за лічені години, на пошук яких у кваліфікованих дослідників пішли б тижні чи місяці. Це стосується і недоліків, прихованих глибоко всередині залежностей з відкритим кодом та транзитивних пакетів, які традиційні інструменти сканування часто пропускають.
Це означає, що часове вікно між прихованим недоліком та експлуатованим експлойтом скорочується, водночас як асистенти кодування на базі ШІ значно збільшують площу атаки.
«Понад 20 років усі наші підходи до роботи з вразливостями базувалися на припущенні, що їх експлуатація є дорогою», — зазначає Квінсі Кастро, директор з безпеки в Chainguard. «ШІ повністю змінив цю динаміку. Ми стоїмо на порозі світу, який буде затоплений новими вразливостями нульового дня (zero-day), і потенційно новими класами вразливостей, які люди раніше не могли виявити. Нульові дні стають набагато більш розповсюдженими».
Коли виявлення вразливостей за допомогою ШІ значно полегшує ідентифікацію слабких місць, прихованих у сучасних стеках залежностей, розрахунок витрат, який робив реактивну безпеку прийнятною, більше не працює.
Інструменти кодування на базі ШІ розширюють поверхню атаки ланцюжка постачання програмного забезпечення
Ризик ланцюжка постачання програмного забезпечення протягом багатьох років підіймався в порядку денному безпеки. Це було зумовлено низкою резонансних компрометацій, які показали, наскільки ефективно зловмисники можуть рухатися через залежності з відкритим кодом, щоб проникнути в корпоративні середовища.
Новий клас слабкостей у робочих процесах CI/CD, який дозволяє зловмисникам захоплювати робочі процеси та компрометувати ланцюжки постачання відкритого коду, отримав кодову назву Cordyceps. Він може надати зловмисникам повний контроль над репозиторіями в десятках найбільших організацій світу, включаючи Microsoft, Google, Apache та Cloudflare.
Наприклад, на Azure Sentinel від Microsoft коментар до pull request міг виконати анонімний код зловмисника на CI Microsoft і викрасти ключ GitHub App, який не мав терміну дії. Pull request до Google AI Agent Development Kit («adk-samples») міг виконати код зловмисника на CI Google, надавши повний контроль над репозиторієм Google Cloud.
У травні платформа відкритого коду GitHub оголосила про витік даних внаслідок атаки на ланцюжок постачання, коли розробник GitHub встановив модифіковане розширення VSCode. Хакерське угруповання TeamPCP, яке стоїть за цим витоком, стверджує, що отримало доступ до приблизно 4000 репозиторіїв коду GitHub. Серед інших жертв — OpenAI та компанія з контрактних даних Mercor. Лише за останні кілька місяців TeamPCP стверджує, що здійснило 20 хвиль атак на ланцюжки постачання, приховавши шкідливе програмне забезпечення (malware) у понад 500 різних програмних продуктах.
Асистенти кодування на базі ШІ прискорюють цю тенденцію, збільшуючи обсяг коду та залежностей, що потрапляють у продакшн. Оскільки розробники випускають кілька релізів на день за допомогою агентних інструментів, поверхня залежностей розширюється зі швидкістю, до якої традиційні робочі процеси сканування та виправлення ніколи не були розроблені.
Водночас, вразливості, які колись могли залишатися невідомими — чи то глибоко в стеку, чи то вважалися надто незначними для пріоритезації — стають легше виявленими у великих масштабах. Питання про те, які недоліки команда безпеки може собі дозволити прийняти, виглядає інакше, коли ШІ може ідентифікувати та потенційно поєднувати кілька менш серйозних проблем в ефективний шлях атаки. Цикл термінових виправлень, який міг відбуватися раз чи двічі на рік, також виглядає зовсім інакше, коли серйозні вразливості з’являються кластерами.
«Кожен раз, коли ви запускаєте процес термінового виправлення, ви ризикуєте зламати частину розгорнутих ресурсів», — каже Кастро. «Ви раптом обираєте між тим, щоб залишити клієнтів під загрозою серйозної вразливості, або порушити роботу продукту, за який вони заплатили».
Реактивні моделі безпеки не встигають за експлойтами, керованими ШІ
Глибша проблема з реактивною безпекою полягає в тому, що вона покладається на все більш неправильне уявлення про те, як насправді відбуваються атаки. Частота виправлень та строки дотримання нормативних вимог передбачають, що вторгнення поводяться як події безпеки — тобто, стохастично передбачувані та керовані ймовірнісним прийняттям ризику.
«Кіберзахист — це не перелік завдань, коли він виконується ефективно», — зазначає Кастро. «Супротивник теж має свій хід. Якщо ви вважаєте, що 30 днів для виправлення критичної вразливості достатньо, ви кожного разу програєте в цій грі».
Просунуті моделі (frontier models) посилюють цю проблему, дозволяючи навіть менш досвідченим зловмисникам швидше рухатися середовищами, поєднуючи вразливості, які раніше вимагали б значної експертизи для експлуатації. Відкриті вразливості, які організації раніше вважали керованими ризиками, тому що їх експлуатація була справді складною, стають більш дієвими в середовищі, де ШІ може допомогти з розробкою експлойтів.
«Керівники безпеки несуть відповідальність за донесення цього зрушення до вищого керівництва», — додає Кастро. «Зміна середовища загроз, спричинена ШІ, — це не те, що традиційні керівники (CXO) впізнають самостійно».
Побудова довіри в момент створення
Найефективнішою відповіддю є наближення безпеки до точки створення програмного забезпечення, а не покладання переважно на виявлення та реагування. Довіра повинна базуватися на походженні програмного забезпечення та довірених джерелах. Замість того, щоб сканувати компоненти після факту та керувати постійно зростаючим списком вразливостей, мета полягає в тому, щоб почати з програмного забезпечення з відкритим кодом, створеного з перевірених джерел, яке постійно підтримується та позбавлене неперевірених залежностей.
Оскільки агентні інструменти кодування роблять розробку програмного забезпечення доступною для неінженерів, співробітник фінансового відділу може створити інструмент для розрахунку податків в IDE, не залучаючи команду безпеки додатків. Модель безпеки, що оточує цей процес, не може покладатися на експертизу, якої розробник не має.
«У Ларрі з фінансів немає команди SRE чи спеціалістів з безпеки додатків, які б наглядали за ним», — каже Кастро. «Він просто намагається виконати свою роботу. Єдиний спосіб, яким це може працювати безпечно в компанії, яка обробляє медичні записи або фінансово чутливі документи, — це якщо компоненти, які він використовує, є невід’ємно безпечними та надійними. Йому не потрібно нічого про це знати. Довіра має бути вбудована на ранніх етапах».
Простота, а не більше інструментів, є вирішенням ризику ланцюжка постачання
Для підприємств, які вже перевантажені складністю програмного забезпечення, посилення існуючих підходів, таких як інструменти аналізу досяжності, розширення команд безпеки додатків, залучення зовнішніх ресурсів для обробки великого обсягу проблем, є програшною стратегією в середовищі, де передові моделі ШІ будуть лише вдосконалюватися.
«Ми ще навіть не торкнулися нових класів вразливостей, які вимагатимуть серйозних змін у широко використовуваних протоколах», — каже Кастро. «У світі недостатньо ресурсів, щоб вирішувати ці проблеми традиційними способами. Замість того, щоб вирішувати складність за допомогою ще більшої складності, ми повинні вирішувати її за допомогою простоти».
На практиці ця простота означає абстрагування безпеки від точки, де її зустрічає більшість розробників, усунення блокуючих процесів сканування-перевірки-виправлення, нашарованих поверх процесу збірки, і заміну їх початковою точкою, яка вже є безпечною за своєю конструкцією. Інженерна команда зберігає свою здатність працювати швидко, а питання довіри вирішується ще до написання коду.
Проте шлях від прискореного виявлення вразливостей до більш стабільного майбутнього вимагатиме реальних змін для організацій, які ще не почали переорієнтовуватися.
«Керівники (CXO) повинні випередити ці проблеми та вживати проактивних заходів для вбудовування безпеки в системи, за які вони відповідають», — каже Кастро. «Ми не хочемо продовжувати інвестувати в те, що вже нас підводить».
Як захиститися (Порада CryptoDom): Активно використовуйте інструменти для статичного аналізу коду (SAST) та аналізу залежностей (SCA) ще на етапі розробки. Переконайтеся, що ваші інструменти оновлені та налаштовані для виявлення потенційних уразливостей, зокрема тих, що можуть бути використані за допомогою нових AI-моделей.
Подробиці можна знайти на сайті: venturebeat.com