Исследователи проверили, как поиск уязвимостей в коде делят между собой обычный статический анализатор (SAST — программа, которая ищет уязвимости по заранее заданным правилам, без запуска кода) и ИИ-агенты. Главный практический вывод для читателя: ни один из двух подходов не закрывает задачу в одиночку, а встроенная команда /security-review в Claude Code по умолчанию «слепа» к нескольким классам уязвимостей — и это зависит от обвязки (harness), а не от модели.
Ключевая находка про поведение агента: когда ИИ «пропускает» уязвимость, виновата не обязательно модель. Встроенная политика команды /security-review исключает атаки типа ReDoS (отказ в обслуживании через «тяжёлое» регулярное выражение) и допускает отчёт про загрязнение прототипа и открытое перенаправление только при очень высокой уверенности. Модель могла бы это найти, но инструкция ей запрещает. Без такой политики та же модель в тех же классах нашла 16 уязвимостей из 20 вместо 9.
Выход из ситуации — смотреть на связку «анализатор + агент» и не доверять встроенной команде вслепую. Анализатор находит то, что агент не репортит по правилам обвязки (например, открытые перенаправления). Агент находит то, что анализатору не по силам: уязвимости, которые проходят через несколько файлов, и ошибки логики доступа.
Схема метода
ШАГ 1: Прогон статического анализатора по репозиторию → список находок (быстро, минуты)
ШАГ 2: Прогон ИИ-агента по тому же коду с общим аудиторским промптом, не с урезанной встроенной командой → отчёт агента
ШАГ 3: Объединение двух списков и ручная проверка спорных мест → итоговый перечень уязвимостей
Шаги 1 и 2 независимы и идут отдельными запросами. Шаг 3 делает человек или отдельный запрос к модели.
Пример применения
Задача: Вы руководите небольшой командой в российском стартапе, где сервис доставки на Python пишут с помощью Claude Code. Перед релизом нужно проверить код на уязвимости. Встроенная команда /security-review вернула «чисто», но есть сомнение, что она смотрит не везде.
Промпт:
Ты проводишь аудит безопасности репозитория этого сервиса доставки.
Проверь все классы уязвимостей без исключений, включая ReDoS (тяжёлые регулярные выражения),
загрязнение прототипа, открытые перенаправления, XSS, SQL-инъекции, обход путей, инъекции команд.
Для каждой находки укажи: класс, файл и строку, где данные приходят от пользователя (источник),
файл и строку, где они попадают в опасную операцию (приёмник), и как это можно эксплуатировать.
Не отбрасывай находки из-за низкой уверенности: пометь уверенность отдельным полем.
Проверяй цепочки, которые проходят через несколько файлов.
Результат: Агент вернёт список находок с указанием источника и приёмника для каждой, с полем уверенности. Среди них должны появиться классы, которые встроенная команда отбрасывала по умолчанию. Часть находок окажется ложной, их придётся проверять вручную.
Почему это работает
Встроенная команда — это не «голая» модель, а модель плюс набор правил, что считать находкой, а что шумом. Правила вшиты, чтобы отчёт был коротким и достоверным. Побочный эффект: то, что правило считает шумом, агент даже не пытается показать. Слабость в том, что читатель видит результат «ничего не найдено» и принимает его за проверку всех классов.
Сильная сторона модели — рассуждать над кодом с учётом контекста: проследить, как данные идут от запроса через несколько файлов к опасному вызову. Анализатор по правилам делает это хуже в логике доступа, зато быстрее и стабильнее в типовых однофайловых шаблонах.
Метод «общий аудиторский промпт вместо встроенной команды» убирает чужие ограничения и возвращает контроль вам. Рычаги: перечень классов в промпте (добавляйте то, что важно именно вам), требование указывать источник и приёмник (так проще проверить находку), поле уверенности (вместо отбрасывания слабых находок).
Шаблон промпта
В видимой части статьи готового текста промпта авторов нет (приложение с промптами обрезано). Ниже общий шаблон по описанному принципу: убрать фильтр по классам и потребовать источник и приёмник.
Проведи аудит безопасности проекта {название_проекта} на языке {язык}.
Проверь все классы уязвимостей без исключений: {список_классов}.
Для каждой находки выведи: класс, файл:строка источника (где приходят данные от пользователя),
файл:строка приёмника (опасная операция), путь данных между ними, как эксплуатировать.
Не отбрасывай находки из-за низкой уверенности. Укажи уверенность: высокая / средняя / низкая.
Отдельно проверь цепочки через несколько файлов и места, где проверяются права доступа.
Что подставлять: {название_проекта} и {язык} — как в вашем репозитории; {список_классов} — все классы, которые вас волнуют (например, XSS, SQL-инъекция, обход путей, инъекция команд, открытое перенаправление, ReDoS).
🚀 Быстрый старт — вставь в чат агента:
Вот шаблон аудита безопасности. Адаптируй под мой проект: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
Агент спросит про язык, структуру проекта и приоритетные классы — потому что без них список классов и формат находок будут слишком общими.
Ограничения
⚠️ Один запуск на ячейку: каждая конфигурация проверена один раз на каждом приложении. Разброс между запусками одного и того же агента авторы не измеряли, поэтому разницу между двумя лучшими вариантами они сами называют статистически неразличимой.
⚠️ Интересы авторов: все авторы работают в Snyk, компании, которая делает анализатор из сравнения. Эталонный набор уязвимостей частично создан с помощью ИИ-ассистента, и авторы сами описывают возможные смещения.
⚠️ Малая выборка: 108 уязвимостей в 20 приложениях, в основном веб-сервисы на четырёх языках. Выводы про другие виды кода и про другие агенты не проверялись.
⚠️ Проверка прохода «без политики»: эксперимент без встроенной политики сделан на 19 из 20 приложений, через месяц после основных запусков, и там не измерено, сколько ложных находок добавилось.
⚠️ Строгая метка: находка засчитывалась, только если указывала и источник, и приёмник с допуском в две строки. Агент мог найти уязвимость, но «промахнуться мимо строки»: в одной из конфигураций Codex Security нашёл 80 уязвимостей на уровне файла, но только 34 — на уровне строки.
Как исследовали
Команда Snyk собрала 20 открытых веб-приложений на Go, JavaScript/TypeScript, Python и Java и вручную составила список из 108 уязвимостей. Каждая из них достижима для внешнего атакующего, для каждой отмечены источник и приёмник данных и проверен рабочий пример эксплуатации. В 62 случаях путь данных идёт через несколько файлов.
Дальше прогнали девять конфигураций вслепую, без подсказок: статический анализатор Snyk Code, /security-review из Claude Code в трёх вариантах (Opus 5, Sonnet 5, Opus 5 с подключённым анализатором), Codex Security в трёх моделях и сканер DeepSec в двух. Находка считалась, только если попадала в источник и приёмник с допуском в две строки.
Результат: Snyk Code нашёл 89 из 108 (82,4%), Claude Code с Opus 5 на высоком усилии — 85 (79,3%). Они расходятся лишь на 28 уязвимостях (16 против 12), и такая разница на этой выборке неотличима от случайной. Вместе они дают 101 из 108 — столько же, сколько все семь сопоставимых конфигураций вместе. Анализатор добавил уязвимости в однофайловых случаях и классах вроде открытого перенаправления; агент добавил семь межфайловых случаев, включая классы авторизации.
Самое показательное: на 20 уязвимостях в «политических» классах Claude Code нашёл 9, анализатор — 18. Когда ту же модель на том же усилии запустили с общим аудиторским промптом вместо встроенной команды, она нашла 16 из 20. Ещё: более дорогая модель не дала лучшего покрытия — Codex Security с GPT-5.6 Sol стоил в 35 раз больше, чем с Luna, и нашёл на 11 уязвимостей меньше. Анализатор просканировал все 20 приложений за 8 минут, а ИИ-конфигурации — за время от 2,4 до 8,9 часа.
Адаптации и экстраполяции
🔧 Техника: добавить требование «источник → приёмник» в любой аудит → проще проверять находки
Для каждой находки укажи, откуда приходят данные пользователя и куда они попадают, с файлом и строкой в обоих местах.
Так ответ можно быстро сверить с кодом, а общие слова вроде «возможна SQL-инъекция» отсекаются.
Экстраполяция: тот же принцип «проверь, что встроенная команда агента не режет нужное» применим к любой готовой команде или скилу агента. Если команда выдаёт «чисто», запросите у неё список правил, по которым она отбрасывает находки.
Ресурсы
How Deterministic SAST and AI Security Agents Divide the Work: Coverage, Harness Policy and Cost in Snyk VulnBench 2.0. Liran Tal, Chris Liu, Charlotte Fereday, Sebastian Roth, Brian Clark (Snyk), октябрь 2026. Авторы сообщают, что код, исходные данные, эталонные наборы и все данные запусков опубликованы. Предыдущая работа: VulnBench JS 1.0.