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