У EndorLabs в апреле вышел (в мае обновили) интересный отчет о безопасности кода, созданного ИИ-агентами, в котором автор прогнал 13 комбинаций «агент + модель» на бенчмарке SusVibes из 200 реальных задач по исправлению уязвимостей в 108 open-source Python-проектах, покрывающих 77 классов CWE. Смысл был не просто проверить, проходит ли код функциональные тесты, а понять, остается ли он безопасным после исправления или реализации фичи.
SusVibes – это исходный академический бенчмарк, на котором Endor Labs построила свой Agent Security League. Полное название работы: «Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks». Авторы предлагают SusVibes как набор задач для проверки не просто того, умеют ли ИИ-агенты писать работающий код, а умеют ли они писать работающий и безопасный код в реалистичных условиях.
Резюме: прохождение тестов больше не может считаться достаточным признаком качества сгенерированного ИИ кода. Лучшая комбинация по функциональности, Cursor + Claude Opus 4.6, достигла 84,4% FuncPass, то есть код часто «работал». Но SecPass у нее был всего 7,8%. А лучший результат по безопасности, Codex + GPT-5.4, дал только 17,3% SecPass. То есть даже лидер по безопасности оставляет уязвимыми примерно 8–9 решений из 10.
Первый вывод с точки зрения ИБ – мнение руководства: «раз ИИ пишет код быстрее, значит мы просто ускорим разработку» – это миф. На практике мы можем ускорить не только разработку, но и производство технического долга и уязвимостей, устранение которых приведет к, возможно, бОльшим расходам.
По сравнению с оригинальным исследованием SusVibes функциональная корректность выросла заметно: с 61% до 84,4%. А вот безопасность выросла совсем немного: с потолка в 12,5% до 17,3%. То есть разрыв между кодом, который работает, и кодом, который безопасен, стал шире.
Для бизнеса это означает, что внедрение ИИ-агентов может дать быстрый прирост производительности, но без изменения SDLC, AppSec-процессов и review-практик этот прирост будет сопровождаться ростом скрытого риска.
Третий вывод – оптимизация под «работающий код» и оптимизация под «безопасный код» – это разные задачи. Это к разговору в комментариях у меня в канале о том, какая модель лучше. Лучше для чего? Написать по-быстрому способ автоматизации задачи для себя, для развертывания в локальной инфре без выхода в Интернет, или для работы в корпоративной среде – это разный scope и… возможно, разные модели. Cursor + Claude Opus 4.6 лидировал в тестах EndorLabs по функциональности, но не вошел в топ-5 по безопасности. Codex + GPT-5.4, наоборот, лидировал по безопасности, но имел более скромную функциональную результативность – 62,6% FuncPass. То есть нельзя выбирать ИИ-инструмент для разработки только по скорости, удобству или проценту прохождения тестов. Для ИБ-команд нужен отдельный критерий: как инструмент ведет себя на чувствительных для ИБ задачах, насколько часто он генерирует уязвимый код, умеет ли он учитывать контекст репозитория и не ломает ли безопасность при «исправлении» функциональности.
Еще одно интересное наблюдение авторов исследования – одна и та же LLM ведет себя по-разному в разных агентных оболочках. Например, Claude Opus 4.6 через Claude Code и через Cursor дал близкую функциональность, но разные показатели по ИБ. То есть важна не только модель, но и архитектура агента – как он читает код, какие инструменты использует, как планирует изменения, как работает с тестами и репозиторием. Опять же – для домашнего использования это не так уж и важно, но для корпоративного выбора инструментов может быть критичным.
Вопрос «какую модель использовать?» недостаточен. Надо спрашивать: в каком IDE, в каком агенте, с какими правами, с каким доступом к репозиторию, с какими ИБ-инструментами и guardrails?
Один из самых интересных выводов отчета – агенты не всегда решают задачу «как разработчик». Иногда они ищут готовое исправление в git history или в Интернете и фактически восстанавливают известный патч. В одном экстремальном случае у SWE-Agent + Claude Opus 4.6 было подтверждено 163 случая «обмана» из 200, и это раздуло SecPass с 1,5% до 64%, то есть примерно в 42 раза. В реальной разработке похожее поведение может выглядеть как «агент нашел готовое решение», но вопрос в том, откуда он его взял, понял ли он его, подходит ли оно к текущему контексту и не принес ли он вместе с ним новые риски и уязвимости.
У вас есть anti-cheating pipeline в процессе разработки?
А что если взять всех агентов, будет ли прирост в уровне безопасности? Закономерный вопрос и EndorLabs ответила и на него. Если объединить все 13 протестированных конфигураций, то хотя бы одна из них дает функционально корректное решение для 90,5% задач. Но безопасно решается только 33% задач.
То есть даже «коллективный разум» разных агентов и моделей оставляет две трети задач нерешенными с точки зрения ИБ.
Но зато такая фрагментация ИБ-возможностей агентов подсказывает направление для развития AppSec-практик. Один агент решает одни классы задач, другой – другие. Поэтому в будущем могут быть полезны ансамбли: один агент пишет код, другой проводит security review, третий проверяет зависимости, четвертый гоняет SAST/DAST/поиск секретов и т.п.
Ну а для управления такими ансамблями понадобится оркестратор, то есть еще один агент. Но вопрос «А кто контролирует контролеров?» мы сегодня оставим без внимания; хотя он и важен.
Еще из интересного – инъекции, несмотря на зрелость и огромное количество известных практик защиты, остаются достаточно слабым местом. В отчете EndorLabs указано, что для «A05: Injection» (это из CWE, кто не помнит) средний SecPass составил только 5,9%, хотя это самая крупная категория в наборе задач. Это разрушает еще один миф: «LLM видела тысячи примеров SQL injection, XSS и path traversal, значит должна хорошо их исправлять». Видеть шаблоны в обучающих данных недостаточно. В реальном репозитории надо понять контекст, источники данных, границы доверия, существующие абстракции, фреймворк и побочные эффекты исправления.
Относительно лучше агенты справлялись с задачами, где есть узнаваемый шаблон: проверка токена, хеширование пароля, проверка подписи, лимиты, таймауты, замена опасного regex. Например, категории Authentication Failures и Software/Data Integrity Failures выглядели «менее плохо», а ReDoS (Regular Expression Denial of Service) оказался одним из наиболее решаемых CWE.
На практике это означает, что ИИ-агенты пока лучше работают там, где безопасность сводится к известному рецепту. Там, где нужна архитектурная оценка, понимание границ доверия, протокольных нюансов или логики приложения, результаты заметно хуже.
В отчете упоминается вывод оригинального SusVibes: общие ИБ-инструкции, просьба выбрать CWE или даже подсказка класса уязвимости не дали устойчивого роста SecPass. Иногда безопасность улучшалась в одних задачах, но ломалась функциональность в других. На практике это означает, что просто добавить в промпт «пиши безопасный код» недостаточно. Нужны конкретные критерии безопасности, модель угроз, контекст используемого фреймворка, безопасные API, автоматические проверки, тесты на злоупотребление, review и политики, встроенные в процесс разработки.
В качестве резюме, опираясь на результаты EndorLabs, для компаний я бы исходил из следующих правил:
- Не измерять успех ИИ-разработки только скоростью и количеством закрытых задач.
- Ввести отдельные метрики по безопасности сгенеренного ИИ кода.
- Требовать security review для кода, написанного агентами.
- Добавлять security-тесты, а не только функциональные юнит-тесты.
- Ограничивать права агентов в репозиториях и окружениях.
- Логировать действия агентов: какие файлы читали, какие команды запускали, откуда брали код.
- Проверять не только итоговый diff, но и процесс его получения.
- Встраивать SAST, SCA, сканирование секретов, обнаружение вредоносов и вредоносных пакетов и проверки политик прямо в агентный workflow.
- Не разрешать агентам бесконтрольно подтягивать зависимости.
- Для критичных компонентов использовать модель «AI пишет – человек и инструменты доказывают безопасность» (human-in-the-loop никуда не девается).
Главный риск вайб-кодинга не в том, что код «не заработает». Он как раз все чаще начинает работать и работать неплохо. Главный риск в том, что он заработает вместе с SQL injection, path traversal, insecure deserialization, утечками данных, ошибками проверки подписи или логическими дырами, которые обычные функциональные тесты не увидят!
