Інтерв’ю
Ronen Slavin, CTO і співзасновник, Cycode – Серія інтерв’ю

Ronen Slavin, CTO і співзасновник, Cycode, – серійний підприємець і колишній офіцер підрозділу 8200 збройних сил Ізраїлю. Перед тим, як запустити Cycode у 2019 році, він співзаснував FileLock, яку у 2018 році придбала Reason Security, і обіймав посаду голови відділу досліджень у Reason Cybersecurity. Завдяки глибоким знанням у сфері виявлення шкідливого ПО, дослідженні уразливостей та експлуатації, Славін побудував кар’єру на перетині передових досліджень безпеки та інновацій продукції.
Cycode – це платформа безпеки застосунків, родна для штучного інтелекту, яка об’єднує команди безпеки та розробників з дієвим контекстом від коду до виконання. Об’єднуючи AST, ASPM та безпеку ланцюга постачання програмного забезпечення, вона захищає як код, згенерований штучним інтелектом, так і код, створений людиною. Завдяки своїй графічній моделі ризиків (RIG), власним сканерам та інтеграціям, Cycode забезпечує миттєве виявлення ризиків, аналіз впливу змін (CIA) та рішення,驱джені штучним інтелектом, – закриваючи прогалини видимості, прискорюючи виправлення та знижуючи витрати з першого дня.
Як вас надихнуло створити Cycode, і яка ключова проблема у сфері безпеки програмного забезпечення ви намагались вирішити з самого початку?
Ідея створення Cycode виникла з того, що ми спостерігали неодноразово: джерельний код викрадається або ненавмисно потрапляє до неправильних рук. Після років роботи у сфері кібербезпеки та наступальної безпеки, а також керівництва захистом кінцевих точок у Reason, ми прийшли до висновку, наскільки критично важливим є джерельний код – не лише як рядки коду, а й як одне з найцінніших активів компанії. Воно не одержувало належної безпеки.
Ця прозріння надихнула мене на створення Cycode. З самого початку наша мета була ясна: захистити джерельний код на кожному етапі, від моменту його написання до моменту його відправлення, все це без перешкоджання розробникам. Ми поставили за мету забезпечити можливість спільної роботи команд безпеки та інженерії, з безпекою, безшовно інтегрованою у щоденний робочий процес, а не як перешкода.
Що мало найбільше значення, так це надання командам видимості, підзвітності та співробітництва, у яких вони потребували. Розробники не повинні жертвувати своєю продуктивністю заради безпеки, а команди безпеки не повинні працювати без контексту чи контролю. Cycode був створений, щоб зробити можливим обидва варіанти.
Як ваш попередній досвід підприємець у сфері кібербезпеки та ваша служба в елітному розвідувальному підрозділі Ізраїлю, Unit 8200, сформували ваш технічний підхід у Cycode?
Мій час у кібербезпеці Ізраїлю, особливо в елітних технічних середовищах, виховував у мені мислення точності, адаптивності та нестримної цікавості. Чи то я був у Unit 8200, чи у своїх перших днях підприємця, я навчився думати як і нападник, і захисник. Це дуальне бачення стало основою того, як ми побудували Cycode.
Як підприємець у сфері кібербезпеки, я бачив на власні очі, наскільки фрагментованим і реактивним стався ландшафт безпеки. Засоби безпеки часто кріпились після факту, залишаючи розробників орієнтуватися у лабіринті попереджень без контексту. Це саме ми й намагались змінити.
У Cycode ми прийняли системний підхід,扱уючи джерельний код як критично важливий актив та будуючи безпеку у життєвий цикл розробки програмного забезпечення з самого початку. Мій досвід навчив мене, що безпека повинна бути проактивною, контекстною та дружньою до розробників. Тому ми так сильно зосереджуємося на автоматизації, видимості та скороченні розриву між безпекою та розробкою програмного забезпечення. Це не лише про знаходження уразливостей, а й про виправлення того, що має значення, швидко.
Cycode поєднує кілька шарів захисту, включаючи AST (тестування безпеки застосунків) та ASPM (управління постатним станом безпеки застосунків). Для тих, хто незнайомий, можете пояснити, як ці елементи працюють разом – і що робить підхід Cycode унікальним?
Абсолютно. У Cycode забезпечення безпеки сучасного програмного забезпечення вимагає більшого, ніж просто сканування коду; воно вимагає всебічного розуміння того, як цей код створюється, розгортається та підтримується. Тепер, як платформа безпеки застосунків, родна для штучного інтелекту, наш підхід є диференціатором через об’єднання Application Security Testing (AST), Application Security Posture Management (ASPM) та Software Supply Chain Security (SSCS).
Засоби AST, такі як SAST, DAST та SCA, ефективні у виявленні уразливостей у коді, залежностях та інфраструктурі. Але вони часто працюють у ізольованих середовищах, генеруючи попередження без контексту. Саме тут вступає в дію ASPM. ASPM з’єднує точки по всьому життєвому циклу розробки програмного забезпечення. Воно забезпечує видимість стану безпеки застосунку з пріоритезацією ризиків та дієвими заходами виправлення, SSCS розміщує платформу для забезпечення безпеки конвеєрів CI/CD.
Що робить Cycode унікальним, так це те, як ми об’єднуємо ці шари та встановлюємо новий корпоративний стандарт. Сьогодні в епоху штучного інтелекту безпека повинна стати розумнішою. Ми побудували свій фундамент з AST, ASPM та SSCS з агентами штучного інтелекту, щоб допомогти пріоритезувати та виправити те, що має значення, швидше, закриваючи ту саму безпекову прогалину, про яку я згадував раніше.
Як Cycode інтегрується з сучасними конвеєрами DevOps, такими як GitHub, GitLab або Azure DevOps, для виявлення ризиків на ранніх етапах життєвого циклу?
Cycode був створений з урахуванням сучасних DevOps. Ми інтегруємося безпосередньо з платформами, такими як GitHub, GitLab та Azure DevOps, щоб вбудувати безпеку у кожну фазу життєвого циклу розробки програмного забезпечення, не сповільнюючи команди.
Наша платформа підключається до систем контролю джерельного коду та CI/CD, щоб безперервно моніторити код, конфігурації та робочі процеси. Ми скануємо та запити на отримання коду в режимі реального часу, щоб розробники отримували негайну зворотню зв’язок про уразливості до того, як код буде об’єднаний. Ми також аналізуємо історію комітів та метадані, щоб призначити питання відповідним власникам, знижуючи тертя та прискорюючи виправлення.
У нашому підході ми не просто поверхнево попередження; ми забезпечуємо повний контекст. Це включає походження питання, його потенційний вплив та кроки для його вирішення. І оскільки ми інтегруємося з інструментами, такими як JIRA, ми можемо автоматично створювати та відстежувати квитки, зберігаючи команди безпеки та інженерії в синхронізації.
У кінцевому підсумку, наша мета полягає в тому, щоб змістити безпеку ліворуч у контрольований, дружній до розробників спосіб, щоб ризики виявлялися на ранніх етапах, вирішувалися оперативно та не ставали перешкодами пізніше в конвеєрі.
Можете пройти нас крізь те, як граф ризиків Cycode допомагає командам зв’язувати загрози по коду, контейнерах, інфраструктурі та виконанню?
Так, це функція, якою ми пишаємося. Граф ризиків, який ми називаємо RIG, – це двигун за можливістю Cycode корелювати та контекстуалізувати дані безпеки по всьому ланцюгу постачання програмного забезпечення.
Подумайте про RIG як про динамічну карту, яка з’єднує все – від джерельного коду та залежностей з відкритим кодом до конвеєрів CI/CD, реєстрів артефактів та середовищ виконання. Вона не просто збирає дані – вона розуміє відносини. Тому, коли виявляється уразливість у контейнері, RIG може простежити її до конкретної рядки коду, розробника, який її здійснив, конвеєра, який її побудував, та інфраструктури, на якій вона працює.
Ця видимість критично важлива. Вона дозволяє командам безпеки пріоритезувати ризики на основі їхнього фактичного впливу, а не лише за рахунок оцінок тяжкості. З штучним інтелектом, вбудованим всередині, вона забезпечує розробникам дієвими знаннями та повним контекстом, дозволяючи їм виправляти питання швидше та з більшою впевненістю.
Важливо відзначити, що RIG не просто панель моніторингу; це інструмент прийняття рішень. Він допомагає командам перейти від виявлення до вирішення з швидкістю DevOps, з’єднуючи точки по фрагментованим системам та поверхнево ризики, які справді мають значення.
Як Cycode виявляє та керує ризиками, пов’язаними з кодом, згенерованим штучним інтелектом, та інтеграціями з сервісами, такими як OpenAI або Hugging Face?
Код, згенерований штучним інтелектом, вводить новий шар складності та ризику, особливо коли він походження з зовнішніх сервісів, таких як OpenAI або Hugging Face. У Cycode ми побудували можливості конкретно для вирішення цієї еволюціонуючої загрози. Нещодавно ми додали агента експлуатації штучного інтелекту та сервер MCP для забезпечення безпеки розробки та робочих процесів кодування.
Що стосується нашої платформи, ми забезпечуємо централізований реєстр активів застосунку, який картографує всі компоненти у екосистемі програмного забезпечення, включаючи моделі штучного інтелекту, бібліотеки штучного інтелекту третіх сторін та інтеграції з сервісами, такими як OpenAI або Hugging Face. Це забезпечує командам повну видимість того, де використовується штучний інтелект, навіть якщо він глибоко вбудований у стек.
Друга, наші власні інструменти аналізу коду роблять значно більше, ніж просте співпадіння з шаблонами. Наш двигун виявлення секретів аналізує шаблони, ентропію та те, як використовується рядок, дозволяючи нам розрізняти справжні секрети та інші сутності, які їм нагадують, такі як тестові дані або текст-заповнювач.
Ми також інтегруємося з системами відстеження питань та робочими процесами розробників, щоб тримати все пов’язане. Коли уразливість або секрет підтверджується та виправляється, ця зворотна зв’язок допомагає нам зробити наші моделі розумнішими. Призначаючи питання на основі власності коду, ми допомагаємо забезпечити, щоб проблеми були спрямовані до правильних людей без зайвої дублікації.
Нарешті, ми допомагаємо організаціям дотримуватися нормативних актів, таких як закон ЄС про штучний інтелект, автоматизуючи документацію та забезпечуючи прозорість того, як штучний інтелект використовується по всьому застосунку. Це включає генерацію звітів про компоненти штучного інтелекту, їх призначення та потенційний вплив, що є критично важливим як для внутрішнього управління, так і для зовнішніх аудитів.
У короткому, Cycode не просто виявляє ризики, пов’язані зі штучним інтелектом; він допомагає керувати ними з повним контекстом, підзвітністю та дотриманням нормативних актів.
Які найбільші виклики у виявленні секретів по сучасним середовищам SDLC, і як Cycode вирішує їх?
Виявлення секретів – одна з найбільш критичних і недооцінених проблем у сучасній розробці програмного забезпечення. Секрети, такі як ключі API, токени та облікові дані, часто кодуються у джерельному коді, конвеєрах CI/CD та файлах конфігурації. І з ростом розподілених команд, залежностей з відкритим кодом та швидких циклів випуску, ці секрети можуть легко просочитися у публічні репозиторії або бути використані атакувальниками.
Виклик полягає в тому, що секрети вже не лише у коді. Вони всюди – у середовищах побудови, реєстрах артефактів та навіть у інструментах третіх сторін. Традиційні сканери часто їх пропускають або генерують надмірний шум, роблячи важким для команд діяти.
У Cycode ми прийняли всебічний підхід до безпеки. Наша платформа сканує весь SDLC, від репозиторіїв коду до конвеєрів CI/CD та середовищ виконання, для виявлення відкритих секретів у режимі реального часу. Ми корелюємо знахідки з контекстом, щоб команди знали не лише те, що було відкрито, а й де, ким і наскільки критично це було.
Ми також забезпечуємо найменші привілеї доступу та безпечні конфігурації конвеєрів, щоб запобігти використанню секретів. І оскільки ми інтегруємося з системами відстеження питань та робочими процесами розробників, виправлення відбувається швидко та без зайвих зусиль.
У кінцевому підсумку, виявлення секретів не лише про те, щоб знайти витік, а й про забезпечення безпеки всієї фабрики програмного забезпечення. Це саме те, для чого побудована платформа Cycode.
Як ви забезпечуєте точність та знижуєте кількість помилкових попереджень при скануванні уразливостей або секретів?
Порівняння з помилковими попередженнями може бути надзвичайно розчаруючим для розробників. Коли команди постійно бомбардуються нерелевантними попередженнями, легко почати їх ігнорувати, і саме тоді справжні загрози можуть прослизнути непоміченими. Через наш двигун SAST ми допомагаємо командам ідентифікувати слабкості коду, досягати точності та зосереджуватися на справжніх позитивах, щоб зберегти час та прискорити доставку програмного забезпечення. У тестах бенчмарку OWASP Cycode досягла рівня помилкових позитивів 2,1%, що представляє зниження понад 94% у порівнянні з альтернативними методами.
По-перше, ми зосереджуємося на кореляції контексту. Замість простого прапорування потенційної проблеми та переходу до наступної, наша платформа асоціює її з більшим контекстом ланцюга постачання програмного забезпечення організації. Тому, якщо секрет виявляється у коміті, ми асоціюємо цю знахідку з конвеєром, який його побудував, середовищем, у якому він був розгорнутий, та розробником, який його додав. Цей додатковий контекст допомагає нам визначити, чи становить реальну загрозу щось, або це просто безпечно.
Далі, наші власні алгоритми сканування роблять значно більше, ніж просте співпадіння з шаблонами. Наш двигун виявлення секретів аналізує шаблони, ентропію та те, як використовується рядок, дозволяючи нам розрізняти справжні секрети та інші сутності, які їм нагадують, такі як тестові дані або текст-заповнювач.
Ми також інтегруємося з системами відстеження питань та робочими процесами розробників, щоб тримати все пов’язане. Коли уразливість або секрет підтверджується та виправляється, ця зворотна зв’язок допомагає нам зробити наші моделі розумнішими. Призначаючи питання на основі власності коду, ми допомагаємо забезпечити, щоб проблеми були спрямовані до правильних людей без зайвої дублікації.
У кінцевому підсумку, наша мета полягає в тому, щоб зробити безпеку чимось, на що команди можуть покластися: менше помилкових попереджень, більш точні знахідки та швидше виправлення. Таким чином, команди можуть зосередитися на вирішенні справжніх проблем, які мають найбільше значення.
Яка цінність “розробник-перший” засобів безпеки, і як Cycode уникнув порушення робочих процесів?
У своєму ядрі “розробник-перший” безпека полягає в тому, щоб зробити захист швидким, актуальним та лише настільки видимим, наскільки це необхідно. Це саме те, як ми зберігаємо розвиток у русі, підтримуючи безпеку програмного забезпечення.
Якщо засоби безпеки сповільнюють розробників або перегружують їх занадто багатьма попередженнями, ці засоби ризикують бути проігнорованими. Це саме те, чому Cycode був створений для допомоги розробникам, а не для їхнього перешкоджання.
Справжня цінність полягає в тому, щоб привести безпеку безпосередньо у щоденний робочий процес розробників. З Cycode безпекові перевірки відбуваються миттєво, саме там, де розробники пишуть та переглядають код, наприклад, у IDE або під час запитів на отримання коду. Це означає, що розробники отримують зворотну зв’язок у той момент, коли їм це потрібно, роблячи легко виявляти питання на ранній стадії та будувати безпечні звички кодування без зайвих зусиль.
Контекст також має вирішальне значення. Замість того, щоб надсилати загальні попередження, Cycode забезпечує розробникам точні деталі: що таке уразливість, де вона походження, хто відповідає за неї та як її виправити. Ций тип інформації допомагає зменшити плутанину та дозволяє командам вирішувати проблеми більш ефективно.
Інтегруючи з популярними інструментами CI/CD та відстеження питань, такими як JIRA, Cycode забезпечує, щоб безпека стала невід’ємною частиною процесу розробки програмного забезпечення, а не чимось окремим чи від’єднаним. Розробники можуть залишатися на завданнях, а команди безпеки отримують нагляд, у якому вони потребують.
Які види атак або уразливостей ви очікуєте зростання, оскільки все більше компаній приймають штучний інтелект у свої робочі процеси розробки?
По мірі того, як штучний інтелект стає все більш інтегрованим у щоденні робочі процеси розробки, ми, ймовірно, зустрінемося з новим набором уразливостей. Ці уразливості не будуть лише технічними проблемами – деякі з них походять від того, як люди та команди взаємодіють з цими інструментами.
Одним із найбільш значимих ризиків є те, що розробники можуть стати надмірно залежними від коду, згенерованого штучним інтелектом. Хоча штучний інтелект може допомогти прискорити процес, він не досконалий. Якщо розробники припускають, що кожна пропозиція штучного інтелекту правильна, вони можуть випадково ввести приховані помилки або уразливості безпеки. Оскільки лінії відповідальності можуть стати розмитими, коли код походження від машини, ці проблеми можуть прослизнути непоміченими.
Є також зростаюча проблема щодо атак на ланцюг постачання, які конкретно націлені на моделі штучного інтелекту та API. Наприклад, якщо довірені сервіси, такі як OpenAI або Hugging Face, будуть скомпрометовані, або якщо хтось просуне шкідливу модель у робочий процес, атакувальники можуть змінити вивід або викрасти конфіденційну інформацію.
Іншою появляється загрозою є отруєння даних. У цьому сценарії атакувальники роблять тонкі, стратегічні зміни у навчальних даних, які можуть пізніше вплинути на те, як поведеться модель штучного інтелекту. Цей тип атаки особливо небезпечний у таких областях, як виявлення шахрайства або контроль доступу, де безпека має критичне значення.
Потім компанії будуть стикатися з зростаючим тиском щодо пояснюваності та дотримання нормативних актів. Нові нормативні акти, такі як закон ЄС про штучний інтелект, будуть вимагати від організацій пояснювати, як їхні системи штучного інтелекту приймають рішення та на основі чого ці рішення приймаються. Це може бути дуже складно, якщо моделі є чорними скриньками або якщо команди використовують інструменти третіх сторін, які не мають прозорості.
У Cycode ми розробляємо інструменти, які допомагають командам ідентифікувати ризики, пов’язані зі штучним інтелектом, такі як уразливості, зловживання моделями та небезпечні інтеграції. Ми також хочемо забезпечити, щоб розробники залишилися відповідальними за код, який вони відправляють, незалежно від того, чи був він написаний людиною, чи згенерований автономно.
Оглядаючи вперед на п’ять років, як ви бачите еволюцію ролі штучного інтелекту у забезпеченні безпеки ланцюга постачання програмного забезпечення?
Штучний інтелект уже трансформує те, як ми підходимо до безпеки застосунків, але його повний вплив на ланцюг постачання програмного забезпечення лише починається. За наступні п’ять років я вважаю, що штучний інтелект стане невід’ємною частиною того, як ми ідентифікуємо, пріоритезуємо та адресуємо ризики протягом усього процесу розробки.
По-перше, штучний інтелект допоможе привести команди безпеки та розробників ближче. Наразі часто існує напруженість, оскільки засоби безпеки можуть переривати робочі процеси або не мати необхідного контексту. Штучний інтелект має потенціал згладити ці краї. Перетворивши знахідки безпеки на дієвими знаннями, рекомендуючи виправлення автоматично та навіть генеруючи безпечні рішення коду, адаптовані до робочого процесу кожної команди.
Штучний інтелект також стане все більш важливим для розуміння того, що відбувається в режимі реального часу. Він буде моніторити середовища побудови, контейнери та API, ідентифікуючи незвичайну діяльність, коли вона відбувається. Це моніторинг у режимі реального часу буде критично важливим, оскільки атаки на ланцюг постачання стають все більш складними та важчими для виявлення за допомогою традиційного сканування.
Крім того, штучний інтелект допоможе компаніям орієнтуватися в зростаючому лабіринті нормативних актів. По мірі того, як уряди вводять більше правил щодо використання штучного інтелекту, організації будуть потребувати інструментів, які можуть пояснити підстави рішень штучного інтелекту, відстежувати походження моделей та забезпечувати підзвітність по всім складним системам. Я бачу штучний інтелект, який вступає у створення документації, картографування залежностей та забезпечення дотримання політики.
Все ж таки, з усіма цими досягненнями, людський нагляд залишиться критично важливим. Штучний інтелект не прийшов заміняти людей, а скоріше наділяти їх можливостями. Розробники та команди безпеки завжди будуть нести відповідальність, особливо коли код, згенерований штучним інтелектом, може ввести нові ризики. Це велика причина, чому ми присвячені будівництву інструментів, які роблять штучний інтелект настільки прозорим, зрозумілим та підзвітним, наскільки це можливо.
У кінцевому підсумку, штучний інтелект стане зв’язуючою ниткою, яка робить ланцюги постачання програмного забезпечення безпечнішими, але тільки якщо ми використовуємо його вдумливо та тримаємо людей залученими на кожному етапі.












