Часть 1 – С чего все началось(и немного теории)

Введение

Начнем из далека чтобы была понятна суть, в июле 2025 года инженер из команды Claude Code в Anthropic – Brian Cherny – написал в X следующее:

«Практически 100% нашего кода написано Claude Code + Opus 4.5. Лично для меня это уже 100% на протяжении двух с лишним месяцев – я даже не делаю правок вручную. Вчера я закрыл 22 пулл-реквеста, позавчера – 27, и каждый из них написан Claude полностью.»
– Brian Cherny, @bcherny

Дальше он добавил: большинство индустрии придёт к похожей статистике в ближайшие месяцы. И что они уже используют claude -p на каждом PR для code review в свежем контексте итд итп что там крч Claude может полноценно работать автономно. Но и сравнительно недавно в марте 2026 года компания DryRun Security опубликовала «The Agentic Coding Security Report» – небольшой, но очень показательный документ. Они взяли трёх кодинг-агентов – Claude (Sonnet 4.6), Codex (GPT 5.2) и Gemini (2.5 Pro) – и дали каждому одно и то же задание: написать два приложения с нуля, добавляя фичи через pull request'ы, как это делает реальная команда разработчиков. После каждого PR прогонялся сканер безопасности. Результаты оказались, мягко говоря, интересными. Вкратце LLM пишут плохо код и согласно отчету 87% pull request'ов содержали хотя бы одну уязвимость и 143 проблемы безопасности суммарно из 38 сканов идр проблемы безопастностей. Выделили вот такой небольшой топик в таблицу повторяющихся проблем.

Класс уязвимости	Уровень	Кто допустил
Broken Access Control	Высокий	Все три агента
Hardcoded JWT secrets	Высокий	Все три агента
WebSocket Auth Bypass	Высокий	Все три агента
IDOR	Высокий	Все три агента
User Enumeration	Средний	Все три агента
XSS	Средний	Gemini + все в отдельных случаях
Race Conditions (TOCTOU)	Средний	Преимущественно Gemini

Что меня удивило: Лучшие результаты показал Codex(я очень надеялся на Claude) – но и у него остались незакрытые JWT-проблемы и отсутствие ревокации токенов.

Вывод из отчёта: LLM пишут неплохо код но все же стоит проверять на безопасность и качество. Поэтому в этой статье мы поговорим о вайбкоде и его безопасности, как довести проект/код, сгенерированный моделью до состояния где он станет более качественным и безопасным чем вообще без проверок :)

Приступим!

Чтобы прочувствовать тот "вайб" вайбкодера, нужно стать им. Но поскольку еще и параллельно нужно решать проблемы я эти проблемы объединил и так получилась идея создания Opensophy Hub, статическая платформа для документации с набором Markdown blocks, dev-панель, интерактивными таблицами, UI-компонентами и live-редактором.

Небольшая теория

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

Туда входит следующие:

покрытие тестами не ниже N%
отсутствие новых уязвимостей
никаких критичных code smell'ов
приемлемая оценка надёжности (например, не ниже B)

В процессе разработки поскольку проект open-source и хочеться бесплатной проверки качества, выбираем SAST инструмент: SonarQube Cloud который проверяет код на каждый push. Если Quality Gate не пройден — GitHub Actions останавливает процесс, и деплой просто не происходит, пока проблемы не исправлены.

Методы ии-интеграции в этом кейсе

Поскольку мы говорим о проекте, который в основном пишет LLM, мы должны избежать эффект когда одинаковая модель "пишет код = делает оценку" иначе услышите от модели "ОЙ. А ОКАЗЫВАЕТСЯ ТЫ ТУТ ПРАВ И ТУТ РЕАЛЬНО УЯЗВИМОСТЬ. СОРЕ" поэтому можно пойти по такому подходу: Claude Sonnet 4.5 пишет код а Claude Sonnet 4.6 исправляет уязвимость. Щас может появиться вопрос "Так это же одинаковые модели. не?" Не совсем. Хоть и по отчету от DryRun Security Claude не в "лучших"(а лучший там Codex) я предпочитаю все же Claude и ее свежие модели(в нашем случае Sonnet 4.5 и Sonnet 4.6 это разные модели по качеству) и наверное личная неприязнь к Codex это то что она делает много лишнего в процессе либо не слушает. Как пример: во время исправлений она зачем-то исправляет код там где вообще не должна трогать! (она мне так темную тему сделала почти синего цвета.) и еще не любит писать код полностью хотя она получила полный доступ к информации о проекте итд итп. у Claude таких проблем нет.

Важно: Модель здесь не заменяет сами инструменты анализа такие как SonarQube Cloud, они остаются основной. Потому что инструмент даёт конкретику — где проблема, в какой строке, какого она типа и насколько критична. Модель уже работает поверх этого списка, а не пытается “на глаз” оценить код целиком. В этом и есть ключевой момент всего подхода.

Часть 2 – подключение SonarQube Cloud и настройка Quality Gate

Наверное избыточно рассказывать про "как проходить регистрации в SonarQube Cloud" мы перейдем сразу к делу. После регистрации проекта в SonarQube Cloud и первичного сканирования переходим в Administration -> Analysis method – там будут перечислены все доступные варианты интеграции: Automatic analysis, GitHub Actions, CircleCI, Manual.

Для каждого из этих вариантов SonarQube Cloud предоставляет готовые инструкции прямо в интерфейсе – Administration -> Analysis method. После выбора нужного метода там будет пошаговый гайд с конкретными командами и конфигурационными файлами под ваш стек.

Текст

Для проекта я выбрал Автоматический анализ. На первый взгляд может показаться, что GitHub Actions – очевидный выбор: больше контроля, явная интеграция в пайплайн. Но для большинства проектов, особенно на старте, автоматический анализ предпочтительнее и все дело в простой настройке. "Нажал и все готово". Прям vibestyle!

GitHub Actions имеет смысл, если вам нужно жёстко заблокировать деплой при непрохождении Quality Gate. Automatic analysis работает асинхронно: SonarQube Cloud анализирует код и сообщает результат, но не может остановить уже запущенный деплой. Если между пушем и завершением анализа проходит хотя бы минута – деплой уйдёт вперёд. А с GitHub Actions можно выстроить цепочку которая блокирует деплой: push -> sonarqube job -> build -> deploy, где build не запустится, пока sonarqube не завершится с успехом.

Если Quality Gate не прошёл, в логах GitHub Actions появится примерно следующее:

ERROR QUALITY GATE STATUS: FAILED
Error: Action failed: The process '...sonar-scanner' failed with exit code 3

И ссылка на дашборд SonarQube Cloud с конкретными проблемами.

Текст

Настройка Quality Gate в SonarQube Cloud

По умолчанию SonarQube Cloud применяет Sonar way – стандартный Quality Gate. Для большинства проектов он вполне адекватен. Посмотреть и скастомизировать его можно в Policies -> Quality Gates.

Стандартные условия Sonar way для нового кода:

Метрика	Порог
Security Rating	A
Reliability Rating	A
Maintainability Rating	A
Coverage	≥ 80%
Duplicated Lines	≤ 3%

Для вайбкод проекта первичная проверка может может показать от 50 до 200+ проблем. Поэтому готовьтесь к марафону на пару часов где например Coverage сразу убьёт Quality Gate. Его конечно на первое время можно убрать и оставить Security и Reliability Rating на уровне A – это разумная планка для любого проекта. Затем можно уже подключать условие по Coverage но это по вашему усмотрению как вы хотите.

В дальнейшем мы расширим sast инструменты, показав проблему такого процесса когда полностью LLM работает с отчетами, в рекомендации еще для полноценной проверки можно добавить SCA(Snyk или GitHub Dependabot) и DAST(HostedScan) инструменты, примеры в скобках имеют бесплатный тариф.

Часть 3 – реальная проверка кода Hub, отчёты, исправления через Claude 4.6

Итак. Допустим, ваш проект уже готов к релизу, SonarQube Cloud подключён, и вы только что посмотрели на результаты первого анализа:

Текст

Жёсткий stonks, да? Это результат для проекта с когда впервые запускаешь анализ после долгой разработки(это прям база базовая поэтому не страшитесь) если смотреть на факты: большинство из этих 234 проблем – code smell'ы. Явные баги в проекте сравнительно редкие, но качество кода страдает именно из-за них и возможных мест где требуется рефакторинг по мнению анализа, поэтому нужно знать что здесь написано в файле иначе если понимаем не до конца, что именно модель сгенерировала в конкретном месте, можем задеть важную часть системы/функции итп.

Пример как можно устранить проблем.

Работать с проблеами и их устранять можно через любой интерфейс – IDE, API, CLI. Лично мне удобнее веб-версия Claude: можно одновременно видеть ход рассуждений модели, прикладывать скриншоты и сразу получать готовый файл. К тому же базовый план бесплатный.

Шаг 1. Пишем промпт

SonarQube Cloud сообщает о проблемах в коде. Проверь и полностью исправь файл. Твоя задача – сделать код максимально простым, читаемым и оптимизированным. При этом учитывай, что необходимо проверять предупреждения на ложные срабатывания (false positive).
Примечание: все комментарии должны быть на русском языке. Не добавляй лишние комментарии – только по функционалу. Никаких комментариев об исправлениях.

Почему такие требования к комментариям: если не указать явно, модель склонна добавлять пометки вида // FIX: исправлен nested ternary или // SONAR: S3358. Это мусор в коде – он иногда не несёт функциональной ценности и захламляет историю. К примеру модель исправила код но не до конца или сделала другие ошибки при изменении файла, из-за чего в нашем случае код будет еще больше из-за комментариев = больше затрат токенов. Поэтому в идеале нужно давать файл/код с минимальными комментариями которые прям нужны. Также можно добавить что LLM при исправлении может добавить NOSONAR комментарий, из-за чего вероятно реальная проблема, например XSS может оставаться в проекте.

Шаг 2. Код

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

Шаг 3. Скриншоты проблем

Переходим в SonarQube Cloud -> Issues или в Security Hotspots (если говорить по приоритету то лучше решить сразу Security Hotspots), делаем скриншоты нужных проблем и прикладываем к сообщению:

Текст

Важный момент: одна и та же проблема может встречаться в файле несколько раз. Например, Prefer globalThis over window у меня было 9 вхождений. Если все они видны на скриншоте – отлично. Если нет – возможно стоит явно указать в промпте: «исправь все вхождения этой проблемы по всему файлу».

По этой же схеме проходим через Security Hotspots и остальные категории issues – делаем до тех пор, пока список не опустеет.

Текст

В результате получаем код, который прошёл статический анализ и соответствует заданному Quality Gate. Это не значит, что он идеален – но это значит, что он объективно лучше, чем до проверки.

Часть 4 – Внедряем дополнительные инструменты и разбираем их подводные камни.

Допустим, предыдущие части пройдены: SonarQube Cloud подключён, CI/CD настроен, проблемы исправлены. Теперь усилим покрытие и добавим ещё один SAST-инструмент – Semgrep.

SonarQube Cloud хоть и покрывает многие проблемы но все же он ориентирован прежде всего на качество кода, тогда как для проверки безопасности предпочитают комбо инструментов и 2ой инструмент для этого будет Semgrep, он сфокусирован на поиске уязвимостей и больше на безопасность. При этом, как и SonarQube Cloud, он предоставляет бесплатный облачный тариф.

Регистрация и настройка Semgrep

Регистрация аналогична SonarQube Cloud. Подмечу тока по интерфейсу: найденные проблемы отображаются в разделе Code, тогда как управление проектами и повторный запуск сканирований – в разделе Projects.

Запуск сканирований

В Semgrep доступно два режима анализа: стандартный (на основе правил) и "ИИ-режим". Поэтому в идеале запускаем оба режима – они могут выявить пересекающиеся, но не идентичные наборы проблем.

Текст

Сюрприз!

Здесь начинается главная проблема подхода. После того как SonarQube Cloud показал чистый результат, Semgrep обнаружил 25 проблем в тех же файлах.

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

Текст

Задача усложняется: нужно исправить то, что нашёл Semgrep, не сломав при этом то, что уже устроило SonarQube Cloud. Это принципиальный момент при работе с несколькими сканерами – исправление под один инструмент может вызвать новые предупреждения в другом.

Попытаемся дать эту таску Claude

Текст

Итог: Модель возвращает исправленный файл. Коммитим, запускаем повторное сканирование и... ничего. Проблемы никуда не делись.

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

Автофикс через Semgrep

Чтобы Semgrep мог делать правки напрямую в репозиторий, нужно выдать ему права на read and write Content доступ к содержимому репозитория. После этого инструмент сам создаёт pull request с исправлениями – остаётся только проверить и смержить.

Текст

Подмечу как пример: В ходе работы через pull request была обнаружена одна некритичная проблема, которая при ближайшем рассмотрении оказалась false positive / (коммит). Это тоже часть процесса: ни один сканер(пока что) не даёт нулевого уровня ложных срабатываний, и умение их идентифицировать – такой же навык, как и исправление реальных уязвимостей.

Это небольшое напоминание что стоит следить за результатами сканов после каждого коммита от Semgrep и других инструментов. Во время которых может сломаться функциональность или сделать ещё хуже.

Итоги

Мы смогли сделать вайб-проект намного чище и безопаснее чем до его проверки, прошли путь от «llm написал код и задеплоил» до воспроизводимого пайплайна, где каждый коммит проходит через несколько слоёв проверки. Это

снижает количество уязвимостей и code smell'ов
даёт структурированный отчёт вместо абстрактного «код плохой»
встраивается в пайплайн и работает автоматически на каждый коммит

Но нет гарантий что SAST-анализ ловит всё. Архитектурные проблемы вроде WebSocket Auth Bypass остаются за его пределами. И текущая схема где агент генерирует -> инструмент анализирует -> агент исправляет не замена code review а лишь бафф для проекта где код пишет в основном LLM. И лучше иметь её, чем не иметь ничего.

Про проблемы:

Галлюцинации при повторных исправлениях. В этом процессе мы редко прибегали к Codex — и не случайно. После 3–4 итераций исправлений он начинает выдумывать: формально закрывает уязвимость, но попутно меняет то, что трогать не просил. Пример: исправил уязвимость, но заодно изменил цвет тёмной темы с чёрного на синий. Чем длиннее сессия и сложнее задача — тем выше риск таких побочных эффектов у Codex.(кстати у Claude могут быть такого же уровня проблемы а-ля "я забыл код. скинь мне его иначе буду писать кашу на основе диалога в чате")
«Докажи мне». Когда специалист по пентесту находит уязвимость, а LLM объявляет это false positive, возникает конфликт, который требует времени на разрешение. Практичное решение — попросить пентестера показать воспроизводимый сценарий эксплуатации: после этого вопрос, как правило, снимается сам собой. А вот если пентестера нету и вы соло-разработчик то стоит напрягать LLM чтобы она показала хотя бы командами как активировать такую уязвимость.
Роль человека в процессе. LLM не может заменить специалиста до тех пор, пока не способна самостоятельно доказать реальность уязвимости, а не просто её задекларировать. Если вы соло-разработчик без глубоких знаний в области безопасности — это повод разобраться в теме, чтобы уметь критически оценивать то, что говорит модель, а не принимать её вывод на веру.

Что ещё для идеала и возможные вопросы:

Если в проекте есть подозрения на архитектурные проблемы — стоит дать модели полный доступ к кодовой базе и попросить провести жёсткий security review без привязки к конкретным файлам. Но важно помнить: по результатам такого анализа неизбежно начнётся очередной цикл правок, а значит, потребуется и очередной прогон инструментов.

Из дополнительных связок стоит упомянуть CodeFactor + SonarQube Cloud: инструменты покрывают частично разные классы проблем. CodeFactor иногда даёт больше false positive, но и находит то, что SonarQube Cloud пропускает.

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