Шахар Мен, співзасновник і генеральний директор Backslash Security – Серія інтерв’ю

Шахар Мен, співзасновник і генеральний директор Backslash Security, – досвідчений лідер у сфері технологій з глибокими знаннями у сфері розробки програмного забезпечення, кібербезпеки та корпоративного програмного забезпечення. Він очолює компанію Backslash Security, яка спеціалізується на захисті середовищ розробки програмного забезпечення, що використовують штучний інтелект, захищаючи все, від інтегрованих середовищ розробки та агентів штучного інтелекту до згенерованого коду та робочих процесів. Раніше він обіймав керівні посади у компанії Aqua Security, де він був віце-президентом з управління продуктами та віце-президентом з досліджень і розробок, допомагаючи створити одну з провідних платформ для безпеки контейнерів на всіх етапах життєвого циклу розробки. На початку своєї кар’єри Мен понад десять років працював у компанії SAP, де він очолював розробку та ініціативи з управління продуктами, включаючи SAP Web IDE, і тісно співпрацював з глобальними клієнтами, а також сприяв зростанню екосистеми розробників. Його кар’єра розпочалася з технічних та керівних ролей у стартапах та оборонних технологічних підрозділах Ізраїлю, що дало йому міцну основу у сфері інженерії та великомасштабних систем.

Backslash Security – це нова платформа кібербезпеки, спеціально створена для епохи розробки програмного забезпечення з використанням штучного інтелекту. Компанія зосереджується на захисті всього стеку розробки, що використовує штучний інтелект, включаючи агентів штучного інтелекту, трубопроводи генерації коду та сучасні робочі процеси розробників, область, яку традиційні засоби безпеки часто ігнорують. Надавши видимість, управління та захист в реальному часі без порушення швидкості розробників, Backslash Security спрямована на вирішення зростаючих ризиків, пов’язаних з автоматичним кодуванням та “вайб-кодіング” середовищами. Оскільки створення програмного забезпечення все більше зміщується у бік систем, що використовують штучний інтелект, платформа призначена для забезпечення того, щоб безпека розвивалася паралельно, а не ставала瓶нем, позиціонуючи Backslash на перетині DevSecOps та наступного покоління розробки штучного інтелекту.

Ви займали керівні посади у сфері продуктів та досліджень і розробок у компаніях Aqua Security та SAP до заснування Backslash. Які ранні сигнали переконали вас у тому, що розвиток програмного забезпечення, заснований на штучному інтелекті, та “вайб-кодіング” фундаментально змінить створення програмного забезпечення, і що безпека повинна бути перебудована для підтримки цього?

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

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

Ви описуєте “вайб-кодіング” як розширення атакувальної поверхні за межі коду у промпти, агентів, сервери MCP та шари інструментів. Які найбільш недооцінені ризики в цьому новому стеку, яких зараз ігнорують розробники та команди безпеки?

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

Традиційна безпека застосунків зосереджувалася сильно на огляді коду. Як думка про безпеку повинна еволюціонувати, коли агенти штучного інтелекту генерують, змінюють та розгортають код в реальному часі?

Безпека повинна перейти від періодичного огляду до безперервного нагляду. Концепція довіри повністю зламана – у вас можуть бути довірені моделі та довірені сервери MCP, але через недетерміновану природу штучного інтелекту вони все одно можуть бути маніпульовані або просто поводитися неправильно, створюючи несподіваний ризик.

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

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

Інструменти, такі як Cursor, Claude Code та GitHub Copilot, стають стандартними у робочих процесах розробників. Де ви бачите найбільші пробіли у безпеці, коли команди приймають ці інструменти без належчого шару управління?

Найбільший пробіл полягає у видимості. У багатьох організаціях ці інструменти поширюються швидко та без офіційного огляду. Команди безпеки часто не знають, які агенти використовуються, як вони налаштовані, які дані вони можуть доступити, або які зовнішні системи вони підключаються до. Це створює проблему “тіньового штучного інтелекту”, яка схожа на “тіньове ІТ” за принципом, тільки швидша та більш динамічна.

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

Третій зростаючий пробіл полягає в тому, що кожен потенційно може стати розробником – те, що ми називаємо “громадянськими розробниками”, які використовують інструменти “вайб-кодіング”. Коли фінансист використовує Claude Code для автоматизації процесів та підключення до внутрішніх систем, це створює потенційний ризик та величезну сліпу пляму навіть сьогодні.

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

Бо ризик не сидить рівномірно всередині будь-якого окремого продукту у вашому стеку. Розробка, заснована на штучному інтелекті, є внутрішньо проблемою екосистеми, оскільки вона працює в багатьох різних місцях, використовуючи багато різних інструментів. Середовище розробки, модель, агенти, сервери MCP, зовнішні плагіни, ідентифікатори та підключені джерела даних всі впливають на те, що будується, і як. Організації свідомо не стандартизують на один інструмент, оскільки їхні відносні сильні сторони змінюються дуже швидко. Якщо ви захищаєте тільки одну точку в цій ланцюжку, ви все одно пропускаєте, як ризик рухається по системі.

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

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

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

Сервери MCP та навички агентів вводять динамічні з’єднання між системами. З точки зору безпеки, чи вони представляють найбільший новий вектор ризику у розробці, керованій штучним інтелектом?

Сервери MCP та навички агентів представляють великий новий шар ризику, оскільки вони визначають, як системи штучного інтелекту підключаються до та взаємодіють з реальним світом. Навички визначають, що агент уповноважений робити, тоді як MCP розширює його доступ до контексту та систем. Разом вони формують фактичну поведінку агента. Якщо ці шари не контролюються щільно, організації втрачають видимість того, що їх інструменти штучного інтелекту можуть зробити, та що вони фактично роблять. Перехід від генерації коду до виконання дій робить це таким критичним областю для безпеки, і вони стають ще непередбачуванішими, коли ви ланцюжите їх разом.

Одна з ваших основних тем – “відділ так” – забезпечення безпеки без сповільнення розробників. Як ви балансуєте захист в реальному часі з швидкістю розробників у середовищах, де швидкість є критичною?

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

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

Ми бачимо, як нontechnічні користувачі все частіше створюють програмне забезпечення, використовуючи інструменти штучного інтелекту. Як зростання нон-розробницьких “вайб-кодерів” змінює ландшафт загроз?

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

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

Оглядаючи вперед на 12-24 місяці, які типи атак або уразливостей ви очікуєте, що виникнуть конкретно через розвиток програмного забезпечення, керований штучним інтелектом?

Ми очікуємо, що багато спільних уразливостей коду будуть避нені заздалегідь через покращення моделей великого мови (LLM) або через краще вкладення правил промптів у “гарнізон”, який оточує ці інструменти. Якщо ми зараз бачимо зростання кількості уразливостей просто через збільшення швидкості, це виправиться само собою. І те, що не виправиться, буде переслідуватися засобами безпеки, активованими штучним інтелектом (SAST і SCA), деякі з яких також будуть надаватися постачальниками платформ штучного інтелекту (наприклад, Claude Code Security та проект Glasswing).

Однак я очікую гірших результатів, коли справа стосується витоків через використання необслуговуваних та необслуговуваних інструментів штучного інтелекту у розробці програмного забезпечення – таких як відкриті агенти (OpenClaw є хорошим прикладом), які мають дуже погані безпекові налаштування, поєднані з користувачами, чия знання безпеки далеко перевершується їхнім ентузіазмом до “вайб-кодіング”.

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

Дякуємо за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Backslash Security.