Часть 1 — С чего всё началось (и немного теории)
Введение
Вайбкод это круто, пока не открываешь первый отчёт сканера безопасности и не видишь 234 проблемы. В статье разберём, как выстроить пайплайн вокруг LLM-проекта: подключить SAST-инструменты, настроить Quality Gate как блокировщик деплоя и использовать модель для исправлений — не вместо инструментов, а поверх них. Покажу на реальном проекте с реальными цифрами. Будет полезно тем, кто активно использует LLM для написания кода, и специалистам в области appsec/devsecops.
Часть 1 — контекст, данные из отчёта DryRun Security и немного теории про DevSecOps.
Часть 2 — подключаем SonarCloud, настраиваем Quality Gate, интегрируем в CI/CD.
Часть 3 — первый скан реального проекта: 234 проблемы, как их разбирать и исправлять через Claude 4.6.
Часть 4 — добавляем Semgrep, смотрим, где инструменты расходятся и где ломается подход.
Начнём издалека, чтобы была понятна суть. В июле 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 прогонялся сканер безопасности. Результаты оказались, мягко говоря, интересными. Согласно отчёту, 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-блоков, 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 подключён к GitHub — вставляем код с проблемами в чат через репозиторий. В моём случае файл был большой, и 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 хоть и покрывает многие проблемы, но всё же он ориентирован прежде всего на качество кода, тогда как для проверки безопасности предпочитают комбо инструментов. Второй инструмент для этого — Semgrep: он сфокусирован на поиске уязвимостей и больше на безопасность. При этом, как и SonarQube Cloud, он предоставляет бесплатный облачный тариф.
Регистрация и настройка Semgrep
Регистрация аналогична SonarQube Cloud. Подмечу только по интерфейсу: найденные проблемы отображаются в разделе Code, тогда как управление проектами и повторный запуск сканирований — в разделе Projects.
Запуск сканирований
В Semgrep доступно два режима анализа: стандартный (на основе правил) и «ИИ-режим». Поэтому в идеале запускаем оба режима — они могут выявить пересекающиеся, но не идентичные наборы проблем.
Сюрприз!
Здесь начинается главная проблема подхода. После того как SonarQube Cloud показал чистый результат, Semgrep обнаружил 25 проблем в тех же файлах.
Это демонстрирует, почему несколько сканеров дополняют друг друга: каждый инструмент работает по своему набору правил и эвристик, и зоны покрытия у них пересекаются лишь частично.
Задача усложняется: нужно исправить то, что нашёл Semgrep, не сломав при этом то, что уже устроило SonarQube Cloud. Это принципиальный момент при работе с несколькими сканерами — исправление под один инструмент может вызвать новые предупреждения в другом.
Попытаемся дать эту таску Claude.
Итог: модель возвращает исправленный файл. Коммитим, запускаем повторное сканирование и… ничего. Проблемы никуда не делись.
Это нередкая ситуация: Semgrep работает по строгим паттернам, и если исправление семантически корректно, но не соответствует ожидаемому паттерну правила — сканер по-прежнему будет его отмечать. В таких случаях стоит попробовать использовать встроенный ИИ-автофикс самого Semgrep, который сделает pull request нам в репо, и проблема снимется.
Автофикс через Semgrep
Чтобы Semgrep мог делать правки напрямую в репозиторий, нужно выдать ему права на read and write Content доступ к содержимому репозитория. После этого инструмент сам создаёт pull request с исправлениями — остаётся только проверить и смержить.
Подмечу как пример: в ходе работы через pull request была обнаружена одна некритичная проблема, которая при ближайшем рассмотрении оказалась false positive (коммит). Это тоже часть процесса: ни один сканер (пока что) не даёт нулевого уровня ложных срабатываний, и умение их идентифицировать — такой же навык, как и исправление реальных уязвимостей.
Это небольшое напоминание о том, что стоит следить за результатами сканов после каждого коммита от Semgrep и других инструментов, во время которых может сломаться функциональность или стать ещё хуже.
Итоги
Мы смогли сделать вайб-проект намного чище и безопаснее, чем до его проверки, прошли путь от «LLM написал код и задеплоил» до воспроизводимого пайплайна, где каждый коммит проходит через несколько слоёв проверки. Это:
снижает количество уязвимостей и code smell’ов;
даёт структурированный отчёт вместо абстрактного «код плохой»;
встраивается в пайплайн и работает автоматически на каждый коммит.
Но нет гарантий, что SAST-анализ ловит всё. Архитектурные проблемы вроде WebSocket Auth Bypass остаются за его пределами. И текущая схема, где агент генерирует -> инструмент анализирует -> агент исправляет, — не замена code review, а лишь бафф для проекта, где код пишет в основном LLM. И лучше иметь её, чем не иметь ничего.
Про проблемы:
Галлюцинации при повторных исправлениях. Codex у меня не прижился, и тому есть конкретная причина. На третьей-четвёртой итерации он начинает чудить: уязвимость формально закрыта, но где-то в другом месте файла что-то изменилось. Однажды после его правок тёмная тема стала синей. Не тёмно-синей, а прям синей. Я потратил время, чтобы понять, откуда это вообще взялось. Поэтому для длинных сессий с большим количеством файлов — Codex мой личный антирекомендейшн. С Claude такого не было, хотя она тоже не святая: если контекст раздувается, модель может попросить скинуть код заново, иначе начнёт работать по памяти о диалоге, а не по реальному файлу.
«А докажи». Бывает такая ситуация: пентестер говорит «вот уязвимость», модель говорит «это false positive». Кто прав? Разбираться можно долго. Самый быстрый способ закрыть вопрос — попросить пентестера показать воспроизводимый эксплойт. Обычно после этого дискуссия заканчивается сама. Если пентестера нет и вы работаете соло — просите модель показать хотя бы команды, которыми теоретически можно активировать уязвимость. Если она не может — возможно, и правда false positive.
Человек в процессе всё ещё нужен. LLM декларирует уязвимость. Не доказывает её, не воспроизводит, не показывает реальный вектор атаки — просто говорит «вот проблема». Это не то же самое, что её реально найти. Поэтому если вы соло без бэкграунда в безопасности — стоит хотя бы базово разобраться в теме, чтобы не принимать вывод модели на веру там, где она может ошибаться.
Что ещё стоит попробовать:
Если есть подозрение, что с архитектурой что-то не так, — можно дать модели полный доступ к кодовой базе и попросить провести security review без привязки к конкретным файлам. Это работает, но готовьтесь к тому, что после такого анализа начнётся новый цикл правок, а значит, снова придётся запускать сканеры.
Из интересных связок, которые я не рассматривал подробно: CodeFactor + SonarQube Cloud. Они покрывают немного разные классы проблем, CodeFactor шумнее по false positive, но иногда ловит то, что SonarQube пропускает.
И последнее — почему только облако. Просто хотелось показать, что это доступно без сервера, без настройки инфраструктуры, бесплатно, прямо сейчас. Если проект попадает под бесплатные тарифы — это нулевой порог входа для нормального анализа.
© 2026 ООО «МТ ФИНАНС»