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

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

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

Вы занимали руководящие должности в продуктах и исследованиях в компаниях seperti 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 месяца, какие типы атак или уязвимостей вы ожидаете появления конкретно из-за потоков разработки на основе ИИ?

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

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

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

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