Інтерв’ю
Заїд Аль Хамані, генеральний директор і засновник Boost Security – Серія інтерв’ю
Заїд Аль Хамані, генеральний директор і засновник Boost Security, є лідером у сфері кібербезпеки та DevSecOps з більш ніж двома десятилітнями досвіду будівництва та масштабування глобальних технологічних операцій. З моменту заснування Boost Security у 2020 році він зосередився на модернізації того, як організації забезпечують безпеку розробки програмного забезпечення, спираючись на попередні ролі, включаючи віце-президента з безпеки застосунків у Trend Micro та співзасновника/генерального директора IMMUNIO. Раніше він обіймав керівні посади у Canonical, очолюючи продукти, інженерні та глобальні ініціативи підтримки, а також у SITA, де керував великомасштабними, критично важливими для місії операціями з інформаційних технологій. Його кар’єра відображає сильний досвід у будівництві команд, оптимізації систем та просуванні сучасних практик безпеки.
Boost Security є компанією з кібербезпеки, що зосереджена на забезпеченні безпеки сучасної ланки постачання програмного забезпечення через платформу DevSecOps, орієнтовану на розробників. Її технологія інтегрується безпосередньо у конвеєри CI/CD для автоматичного виявлення, пріоритезації та виправлення уразливостей, зменшуючи ручну роботу при збереженні швидкості розробки. Об’єднуючи безпеку застосунків та ланки постачання у єдину систему, платформа забезпечує повну видимість коду, залежностей та інфраструктури, допомагаючи організаціям посилювати стійкість у складних, хмарних середовищах.
Ви раніше очолювали безпеку застосунків у Trend Micro та були співзасновником IMMUNIO. Що спонукало вас заснувати Boost Security, і яку прогалину на ринку ви були унікально позиціоновані для ідентифікації на ранній стадії?
IMMUN.IO була однією з перших компаній RASP, заснованих у цій сфері – і наш досвід до того моменту показував, що технологія безпеки в режимі виконання була важкою для підтримки та не дуже ефективною. Ми бачили шлях, яким можна було би замінити засоби безпеки в режимі виконання на більш точні та легші у підтримці рішення – шляхом інструментування застосунку.
Це було у 2012 році, коли DevOps ще тільки з’являвся, більшість команд не використовували агіл, а Kubernetes ще не існував.
Trend Micro придбала IMMUN.IO у 2017 році. На той момент вже існували численні практики DevOps: конвеєри CI/CD, агіл-розробка, швидкі ітерації та цикли випуску, хмарні технології тощо. Команди з розробки програмного забезпечення стали краще у будівництві програмного забезпечення та його доставці. Однак безпека все ще була порушена:
- Сканиування відбувається занадто повільно, або результати надходять занадто пізно
- Результати надто складні для розробників, щоб вони могли діяти
- Існує загально неприйнятний рівень помилкових позитивних результатів
- Багато нових типів артефактів не скануються: інфраструктура як код, контейнери, API тощо
Виробництво програмного забезпечення швидко стало легшим. Однак виробництво безпечного програмного забезпечення швидко все ще було складним.
Це була原始на проблема, яку ми поставили собі за мету вирішити. Зробити DevSecOps ефективним у реальному світі; чи можна змусити команду розробників легко додати безпеку до циклу розробки програмного забезпечення, зі швидкістю, що відповідає новим стандартам швидкості? Чи можна зробити охоплення широким – де одна платформа є всім, що вам потрібно? Чи можна зробити так, щоб розробники, а не лише приймали технологію, але й бачили її користь? Чи можна зробити так, щоб вона масштабувалася, щоб вам не потрібно було великої кількості фахівців з безпеки, щоб слідкувати за кількістю написаного коду…
Ми допомогли компаніям впровадити безпеку у цикл розробки програмного забезпечення під час епохи DevOps. Це було перехід від 1 до 10. Тепер ми перебуваємо в епоху агентського кодування – де агенти пишуть величезну кількість коду – але це фундаментально та сама проблема – швидкість та обсяг коду просто перейшли від 10 до 100; і ми маємо продовжувати ту саму траєкторію.
Ви стверджували, що життєвий цикл розробки програмного забезпечення (SDLC) суттєво зсунувся вгору. Який був момент, коли ви зрозуміли, що традиційні підходи до DevSecOps більше не є достатніми?
Це було спостереженням за тим, як атакувальники насправді проникали всередину. Ми постійно бачили одну й ту саму картину: відкритий робочий процес GitHub Actions, який ніхто не переглядав від моменту форкування репозиторію, токен з доступом до виробництва, закладений у конфігурації запуску, легітимна робота CI, захоплена для розгортання вантажів атакувальників. Це стало відомо як атаки “живучи з конвеєра”, оскільки противник використовує вашу власну автоматизацію проти вас, з вашими ж затвердженими уповноваженнями безпеки.
Стек DevSecOps, який ми побудували за десятиліття, не мав відповіді на це. Сканування застосунку джерельного коду здійснюється за допомогою SAST. Сканування застосунку залежностей здійснюється за допомогою SCA. Обидва припускають, що конвеєр, який їх запускає, є довірчим. Тим часом сам конвеєр є файлом YAML з командами shell, доступом до мережі та чутливими уповноваженнями, і майже ніхто не переглядає його.
Коли це стає найлегшим шляхом, ви можете доставити ідеально чистий код і все одно передати атакувальникам ваш хмарний сервіс.
Як підприємства повинні переосмислити SDLC у світі, де агенти штучного інтелекту генерують код безперервно, а не розробники пишуть його крок за кроком?
Ми всі повинні停止 думати про SDLC як про послідовність перевірок. Агенти штучного інтелекту звузили час між “хтось написав це” і “це вже у виробництві” з тижнів до хвилин. Стара модель припускала людську каденцію між кодом, перевіркою, SAST, SCA та розгортанням, але ми вже вийшли за ці рамки.
Безпека повинна існувати там, де працює агент: на машині розробника, всередині контексту запиту, у зв’язках агента з серверами MCP та зовнішніми моделями. До того моменту, коли код досягає конвеєра, ви вже втратили шанс сформувати його. Агент уже витягнув залежність. Модель вже бачила уповноваження. Перемістіть контролю вище, туди, де відбувається робота.
Багато організацій все ще розглядають інструменти кодування штучного інтелекту як прості шари продуктивності. Чому ви вважаєте, що вони представляють абсолютно нову поверхню атаки, а не просто розширення існуючих робочих процесів?
Розгляд інструменту кодування штучного інтелекту як шару продуктивності подібний до розгляду молодшого розробника з доступом root як шару продуктивності. Мітка технічно точна, але вона не дає вам жодної корисної основи для думок про те, що може піти не так.
Інструмент кодування штучного інтелекту читає вашу файлову систему, витягує змінні середовища для контексту, витягує залежності з публічних реєстрів, відкриває з’єднання з віддаленими постачальниками моделей та серверами MCP, та виконує команди shell. Кожна з цих дій раніше вимагала людини у циклі. Тепер вони відбуваються за мілісекунди, з тими ж привілеями, що й у розробника, який запустив агента.
Це злиття довірчих кордонів, які раніше були окремими: уповноваження розробника, те, що може витягнути зовнішній інструмент, та те, що може виконати недовіряний код. Це створює нові можливості для атакувальників та сліпі плями, які захисники навіть не можуть бачити, не кажучи вже про захист.
Boost розглядає ноутбук розробника як нову площину контролю. Які ризики існують на кінцевому пристрої, яких зараз не бачать команди з безпеки?
Найбільший ризик полягає в інвентаризації. Більшість команд з безпеки не можуть сказати вам, які агенти штучного інтелекту працюють на яких ноутбуках, до яких серверів MCP ці агенти підключені, або які розширення IDE зараз витягують вміст репозиторію. EDR не має видимості до рівня агента; SIEM також не може бачити, що ці агенти роблять локально.
Під цим лежить хаос з уповноваженнями. Ми побудували інструмент відкритого коду під назвою Bagel частково для того, щоб зробити це конкретним. Типовий ноутбук розробника містить токени GitHub з правами запису до репозиторію виробництва, уповноваження хмари, які можуть розгорнути інфраструктуру, токени npm або PyPI, які можуть публікувати мільйони користувачів, та ключі служби штучного інтелекту, які атакувальники перепродають. Ніщо з цього не укріплено так само, як укріплений CI-запуск. Та сама машина, яка містить ці уповноваження, також переглядає веб та встановлює випадкові розширення VS Code.
Об’єднайте два і ви отримуєте фактичну поверхню атаки. Недовіряне розширення, яке працює з привілеями розробника в середовищі, повному ключів хмари, є найбільш високоефективною ціллю у сучасному підприємстві. Більшість команд ще не почали розглядати це.
Ви підкреслили “пастку контексту”, де агенти штучного інтелекту можуть отримувати доступ до локальних файлів, змінних середовища та конфігурацій. Наскільки поширений ризик витоку чутливої інформації через запити, і чому його так складно виявити?
Достатньо поширений, щоб ми розглядали це як стандартний стан будь-якого неуправляемого середовища розробника. Кожен інструмент кодування штучного інтелекту, який ми оглянули, агресивно витягував локальний контекст. Вони читали файли з крапкою, змінні середовища, недавні файли, іноді цілі дерева каталогів, та відправляли цей контекст на віддалену модель. Інструменти розроблені для роботи саме так; агресивне витягування контексту робить їх корисними.
Проблема виявлення починається з того, що трафік з витоку виглядає ідентично до нормального використання продукту. Це TLS до api.openai.com або api.anthropic.com. Це надходить від затвердженого бізнес-додатка. Стандартний DLP бачить розробника, який використовує інструмент штучного інтелекту, який компанія тільки що придбала ліцензію. Він не бачить, що одна з рядків у цьому запиті є ключем AWS, який агент витягнув з напівзабутого файлу .env у братньому каталозі.
Ви ловите це лише шляхом інспекції запитів до того, як вони покинуть ноутбук, що є саме тим місцем, де майже жодна система безпеки зараз не позиціонується.
Ви згадали атаки на ланцюг постачання зі швидкістю машин. Можете роз’яснити реалістичний сценарій, у якому агент штучного інтелекту вводить уразливість швидше, ніж традиційні інструменти безпеки можуть її виявити?
Ось один з тих, яких ми бачили у різних варіаціях повторно. Розробник просить агента додати функцію, яка потребує бібліотеки повторної передачі HTTP. Агент пропонує назву пакету. Пакет звучить правдоподібно, але насправді не існує на npm. За годину атакувальник реєструє його, заповнює робочою логікою повторної передачі, плюс невеликим скриптом після встановлення, який читає ~/.aws/credentials та надсилає вміст на вебхук. Агент запускає npm install без перевірки, оскільки агенти не перевіряють репутацію. Уповноваження втрачено до того, як розробник навіть запустить код.
Сама атака не є технічно складною, але традиційна безпека ланцюга постачання побудована навколо відомих уразливостей у відомих пакетах: CVE, SBOM, сканування ліцензій. Ця структура нічого не говорить про пакет, який не існував на момент останнього сканування, був створений спеціально для відповіді на галюцинацію штучного інтелекту, та інгестується до того, як оновляться будь-які потоки загроз.
Вікно від публікації до компрометації тепер вимірюється хвилинами. Все, що перевіряється після факту, перевіряється занадто пізно.
Чи стають галюциновані залежності однією з найбільших ризиків у розвитку, керованому штучним інтелектом, та які практичні кроки можуть організації зробити для захисту від них?
Вони вже однією з найбільших. Атакувальники активно моніторять популярні інструменти штучного інтелекту на галюцинації та реєструють запропоновані імена пакетів протягом хвилин. Дослідники кілька років тому, коли це тільки почалося, називали це slopsquatting, і назва прижилася. Як тільки ім’я залежності галюцинується досить часто, сидіння на ньому стає пасивною атакою на ланцюг постачання з майже нульовими зусиллями.
Практичні захисти виглядають інакше, ніж те, що більшість команд зараз має. Почніть з інгестії. Блокуйте пакети з помилками у назві та новостворені пакети в момент запуску npm install або pip install, на машині розробника, до того, як щось потрапляє на диск. Постмортем виявлення у CI не допомагає, коли пост-установочний скрипт вже екзфільтрував уповноваження. Потім надайте агенту обмеження для роботи всередині. Впровадьте список затверджених залежностей безпосередньо у контекст агента, щоб модель бачила, що дозволено, до того, як генерує пропозицію. Прохання до розробників написати “безпечні запити” не є стратегією. Якщо ви стратегічні, то безпека встановлює межу, а агент успадковує її. І почніть відстежувати Білль матеріалів штучного інтелекту. Більшість команд не можуть сказати вам, які агенти, моделі та пакети торкаються яких репозиторіїв. Ви не можете захистити те, що не можете інвентаризувати.
Ви сказали, що безпека вже не може починатися з CI/CD. Як виглядає сучасний безпечний конвеєр, коли захист потрібно розпочинати раніше у процесі розробки?
Якщо безпека починається з CI/CD, ви поступилися цілим пре-комітному етапу середовищу, яке не контролюєте. Агент уже витягнув контекст, ваше уповноваження може вже бути в логах хазяїна.
Сучасний конвеєр починається на ноутбуці. Це означає інвентаризацію агентів та розширень, які працюють там, перевірку, до яких серверів MCP та моделей вони підключені, санітарну обробку того, що залишає машину, та блокування шкідливих пакетів до їх встановлення. Від那里 політика слідує роботі до IDE. Ми впроваджуємо стандарти безпеки безпосередньо у вікно контексту агента, щоб згенерований код залишався всередині обмежень з першого токена. Конвеєр все ще працює, здійснюючи остаточну верифікацію контролю, які вже були примусово застосовані вище.
Сам конвеєр не зникає. Його роль стає верифікацією: підтвердженням того, що контрольні заходи вище трималися.
Як організації продовжують впроваджувати агенти кодування штучного інтелекту, які найкритичніші зміни вони повинні зробити сьогодні, щоб забезпечити, що їх середовища розробки залишаються безпечними протягом наступних кількох років?
Найбільша помилка полягає в тому, що безпека охоплює лише те, що комітиться. Цікавий ризик зараз живе у восьми годинах до коміту. Невидима драма може розгортатися на ноутбуці, у запиті чи під час встановлення пакету. Якщо ваші інструменти починаються з PR, ви захищаєте неправильну половину робочого процесу.
Тісно пов’язано з цим: перестаньте розглядати інструменти кодування штучного інтелекту як програмне забезпечення для продуктивності. Вони є нелюдськими користувачами з доступом shell, привілеями запису репозиторію та зовнішніми мережевими з’єднаннями. Керуйте ними так само, як керуєте будь-якою іншою привілейованою ідентичністю, з інвентарем, затвердженими можливостями та журналами аудиту.
Останній зсув є культурно складнішим. Більшість поточних інструментів “безпеки штучного інтелекту” висвітлюють результати та маршрутизують їх до людей. Люди не можуть тріажевати зі швидкістю, з якою агенти генерують. Все, що ви приймете, повинно автоматично вирішувати питання всередині робочого процесу, з відстежуваним rozumуванням, або це стане ще одним панелем, який ніхто не читає.
Дякуємо за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Boost Security.
