Шахар Ман, сооснователь и генеральный директор Backslash Security – Интервью

Шахар Ман, сооснователь и генеральный директор Backslash Security, является опытным технологическим лидером с глубокими знаниями в области облачных разработок, кибербезопасности и программного обеспечения для предприятий. В настоящее время он руководит компанией Backslash Security, которая фокусируется на защите сред разработки программного обеспечения на основе ИИ, защищая все, от IDE и агентов ИИ до сгенерированного кода и рабочих процессов подсказок. До этого он занимал руководящие должности в компании Aqua Security, где он был вице-президентом по управлению продуктами и вице-президентом по исследованиям и разработкам, помогая создать одну из ведущих платформ для безопасности контейнеров на протяжении всего жизненного цикла разработки. Ранее в своей карьере Ман провел более десяти лет в компании SAP, где он руководил разработкой и инициативами по продуктам, включая SAP Web IDE, и тесно сотрудничал с глобальными корпоративными клиентами, а также вносил вклад в рост экосистемы разработчиков. Его карьера началась с технических и руководящих ролей в стартапах и израильских оборонных технологических подразделениях, давая ему прочную основу как в инженерии, так и в крупномасштабных системах.

Backslash Security – это появляющаяся платформа кибербезопасности, предназначенная для эпохи разработки программного обеспечения на основе ИИ. Компания фокусируется на защите всего стека разработки на основе ИИ, включая агентов ИИ, конвейеры генерации кода и современные рабочие процессы разработчиков, область, которую традиционные инструменты безопасности часто упускают из виду. Предоставляя видимость, управление и защиту в реальном времени без нарушения скорости разработки, Backslash стремится решить растущие риски, введенные автоматизированным кодированием и “вибрационными” средами разработки. Поскольку создание программного обеспечения все больше смещается в сторону систем, поддерживаемых ИИ, платформа предназначена для обеспечения того, чтобы безопасность развивалась параллельно, а не становилась узким местом, позиционируя Backslash на пересечении DevSecOps и следующего поколения разработки ИИ.

Вы занимали руководящие должности в продуктах и исследованиях в компаниях Aqua Security и SAP до основания Backslash. Какие ранние сигналы убедили вас, что разработка на основе ИИ и “вибрационное” кодирование фундаментально изменят создание программного обеспечения, и что безопасность должна быть перестроена, чтобы поддержать это?

Я уже пережил один крупный сдвиг, когда программное обеспечение перешло в облачные архитектуры. В SAP и позже в Aqua мы увидели своими глазами, что когда разработка меняется так сильно, безопасность обычно отстает. ИИ довел эту истину до совершенно нового уровня, не только потому, что он может помочь писать код быстрее, но и потому, что он начал менять всю среду вокруг создания программного обеспечения.

Защита кода теперь менее связана с самим кодом и более с окружающей средой. За менее чем год то, что раньше было относительно ограниченной и низкорисковой средой разработки, расширилось в обширную, высоко связанную поверхность атаки с минимальным контролем или управлением. Как только это произошло, вопросы безопасности вокруг уязвимостей кода полностью изменились. Реальная проблема не в том, является ли данный фрагмент кода уязвимым. Проблема в том, что, разрешая разработку на основе ИИ, мы ввели системы, агенты, интеграции и пути доступа, которые выходят далеко за пределы самого кода. Безопасность больше не может фокусироваться только на выходе кода. Она должна учитывать всю среду, которая делает этот код возможным.

Вы описываете “вибрационное” кодирование как расширение поверхности атаки за пределы кода в подсказки, агенты, серверы MCP и слои инструментов. Какие наиболее неправильно понимаемые риски в этом новом стеке разработчиков и команд безопасности в настоящее время упускают из виду?

Самое большое недоразумение заключается в том, что многие команды все еще думают, что риск живет в основном в сгенерированном коде. Это только один слой. В разработке на основе ИИ риск вводится раньше и в многих местах. Это может быть в подсказках, контексте, предоставленном модели, разрешениях, предоставленных агентам, серверах MCP, к которым они подключаются, или внешних инструментах и плагинах, которые расширяют их возможности. Один ноутбук пользователя может быть захвачен и использован как плацдарм для более широкой атаки. Это проблема с конечной точкой, маскирующаяся под проблему кодирования ИИ. В отличие от уязвимостей кода, это не только ставит ваши приложения под угрозу – это может поставить под угрозу всю вашу организацию. Если вы смотрите только на код, вы упускаете большую часть картины.

Традиционная безопасность приложений фокусировалась сильно на проверке кода. Каким образом мышление безопасности должно эволюционировать, когда агенты ИИ генерируют, изменяют и развертывают код в реальном времени?

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

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

Кроме того, мы не можем игнорировать роль ИИ и моделей ИИ в обработке уязвимостей. Если год назад модели ИИ давали много уязвимостей по умолчанию, то дела значительно улучшились, и другие модели теперь используются для обнаружения нулевых дней, которые никогда раньше не были найдены. Итак, мы движемся к лучшим результатам – но кто следит за магазином, пока мы это делаем? Атакующие смотрят в другом месте.

Инструменты, такие как Cursor, Claude Code и GitHub Copilot, становятся стандартными в рабочих процессах разработчиков. Где вы видите самые большие пробелы в безопасности, когда команды принимают эти инструменты без надлежащего слоя управления?

Самый большой пробел – это видимость. Во многих организациях эти инструменты распространяются быстро и без формального обзора. Команды безопасности часто не знают, какие агенты используются, как они настроены, какие данные они могут получить доступ, или какие внешние системы они подключены. Это создает проблему “тени ИИ”, которая по сути аналогична “тени ИТ”, только быстрее и более динамичной.

Второй по величине пробел – это отсутствие принудительных политик. Большинство организаций могут иметь руководства, но руководства сами по себе не помогают много, когда разработчик движется быстро внутри IDE. Без управления на уровне инструмента и рабочего процесса команды рискуют получить инструменты с чрезмерными полномочиями, которые не соответствуют корпоративным стандартам. Эти инструменты сами по себе не плохи, но их принятие без управления означает, что вы эффективно масштабируете скорость разработки без масштабирования контроля.

Третий возникающий пробел заключается в том, что любой может потенциально стать разработчиком – то, что мы называем “гражданскими разработчиками”, использующими инструменты “вибрационного” кодирования. Когда финансовый сотрудник использует Claude Code для автоматизации процессов и подключения к внутренним системам, это создает потенциальный риск и является огромной слепой зоной даже сейчас.

Backslash фокусируется на защите всей экосистемы разработки ИИ, а не отдельных инструментов. Почему этот полноэкранный подход необходим, и что происходит, если организации продолжают рассматривать эти риски в изоляции?

Потому что риск не сидит аккуратно внутри любого продукта в вашем стеке. Разработка на основе ИИ является по своей сути проблемой экосистемы, поскольку она работает во многих разных местах, используя множество разных инструментов. IDE, модель, агенты, серверы MCP, внешние плагины, идентификаторы, подключенные данные и источники все влияют на то, что строится и как. Организации намеренно не стандартизируют на один инструмент, потому что их относительные сильные стороны меняются так быстро. Если вы защищаете только одну точку в этой цепи, вы все равно упускаете из виду, как риск перемещается по системе.

Рассмотрение этих рисков в изоляции приводит к фрагментированным защитам и опасным слепым зонам. Вы можете укрепить сканер кода, но упустить из виду сервер MCP, который подал рисковый контекст в модель. Это причина, по которой мы считаем, что правильный подход – это полноэкранная видимость и защита в реальном времени на протяжении всей экосистемы разработки ИИ. В противном случае организации будут продолжать решать симптомы, пока фактическая поверхность атаки продолжает расширяться под ними.

Подсказки появляются как новый слой программирования. Как организации должны подойти к защите подсказок и предотвращению проблем, таких как внедрение подсказок, утечка данных или манипуляция?

Подсказки все больше формируют логику и поведение. Во многих случаях они эффективно являются новой контрольной плоскостью для создания программного обеспечения. Это означает, что им необходимы политика, мониторинг и ограничители, как и определения кода или инфраструктуры. Практически это начинается с ограничения того, к чему подсказки могут получить доступ, и каких действий они могут запустить. Это также означает определение правил подсказок, соответствующих ожиданиям безопасности и качества, предотвращение раскрытия конфиденциальных данных через окна контекста и наблюдение за попытками манипуляции, такими как внедрение подсказок или косвенное взлом инструкций. И это также включает в себя обеспечение того, чтобы сами правила не использовались как задние двери для внедрения подсказок. Более широкая точка зрения заключается в том, что вы не защищаете подсказки, инструктируя разработчиков и агентов “быть осторожными”. Вы защищаете их, встраивая контроли в среду, где фактически происходит подсказка.

Серверы MCP и навыки агентов вводят динамические связи между системами. С точки зрения безопасности, представляют ли они наиболее значительный новый вектор риска в разработке на основе ИИ?

Серверы MCP и навыки агентов представляют собой значительный новый слой риска, поскольку они определяют, как системы ИИ подключаются к и взаимодействуют с реальным миром. Навыки определяют, что может делать агент, а MCP расширяет его доступ к контексту и системам. Вместе они формируют фактическое поведение агента. Если эти слои не строго контролируются, организации теряют видимость того, что могут делать и что фактически делают их инструменты ИИ. Сдвиг от генерации кода к выполнению действий является тем, что делает эту область так критической для безопасности, и она становится еще более непредсказуемой, когда вы соединяете их вместе.

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

Безопасность создает трение, когда она происходит поздно или отключена от того, как фактически работают разработчики. Она становится гораздо более эффективной, когда она встроена直接 в рабочий процесс и фокусируется на том, что действительно имеет значение. Это была часть нашего мышления с момента основания Backslash, и это имеет еще большее значение сейчас в разработке на основе ИИ.

На практике это означает выявление немногих проблем, которые представляют реальный риск, а не наводнение разработчиков всем, что выглядит теоретически подозрительным. Это означает обеспечение соблюдения политики в IDE и рабочем процессе агента, а не после факта. И это означает создание прозрачных, детерминированных ограничителей, чтобы команды могли двигаться быстро, зная, какие инструменты используются, какие разрешения у них есть и когда происходит что-то необычное. Цель – не замедлить принятие ИИ, а помочь организациям принять его уверенно, не теряя контроля. В реальных терминах это означает, что разработчику будет меньше места для ошибок, но если он совершит ошибку, она будет быстро обнаружена и устранена.

Мы наблюдаем, как неквалифицированные пользователи все чаще строят программное обеспечение, используя инструменты ИИ. Как рост неквалифицированных разработчиков “вибрационного” кодирования меняет ландшафт угроз?

Он расширяет ландшафт угроз двумя способами. Во-первых, он значительно увеличивает количество людей, которые могут производить программоподобные результаты, не понимая последствий безопасности. Во-вторых, он создает ложное чувство безопасности, потому что инструменты делают разработку похожей на разговор и низкозатратную.

Это означает, что организации увидят больше приложений, автоматизаций и интеграций, созданных людьми, которые не обучены учитывать границы доверия, проверку входных данных, гигиену зависимостей, контроль доступа или раскрытие данных. Другими словами, поверхность атаки расширяется не только потому, что ИИ пишет больше кода, но и потому, что больше людей могут теперь генерировать рабочие процессы и системы, которые ведут себя как программное обеспечение, не применяя базовые инженерные дисциплины. Это делает видимость и встроенные меры безопасности еще более важными, потому что вы больше не можете предполагать знания безопасности в точке создания.

Оглядываясь вперед на 12-24 месяца, какие типы атак или уязвимостей вы ожидаете появления конкретно из-за рабочих процессов разработки на основе ИИ?

Мы ожидаем, что многие общие уязвимости кода будут избегаться заранее благодаря улучшениям в самих моделях ИИ или благодаря лучшим встроенным правилам подсказок в “гарнитуре”, окружающей эти инструменты. Если мы сейчас наблюдаем увеличение количества уязвимостей просто из-за увеличения скорости, это исправится. И то, что не исправится, будет преследоваться с помощью инструментов безопасности, поддерживаемых ИИ, и SCA (некоторые из которых также будут предоставлены поставщиками платформ ИИ, например, Claude Code Security и проект Glasswing).

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

В результате я думаю, что мы увидим сдвиг в сторону атак, нацеленных на саму экосистему разработки, а не только на системы производства. Поскольку ИИ становится частью того, как создается программное обеспечение, атакующие будут фокусироваться на манипулировании инструментами и связями, которые формируют этот процесс, эффективно компрометируя программное обеспечение еще до его развертывания.

Спасибо за отличное интервью, читателям, которые хотят узнать больше, следует посетить Backslash Security.