В марте 2026 года компания DryRun Security опубликовала «The Agentic Coding Security Report». Исследователи дали трём ИИ-агентам — Claude (Sonnet 4.6), Codex (GPT 5.2) и Gemini (2.5 Pro) — одинаковое задание: написать два приложения с нуля, добавляя функциональность через pull request'ы. После каждого PR запускался сканер безопасности. Итог: 87% PR содержали хотя бы одну уязвимость, суммарно — 143 проблемы в 38 сканах. Лучший результат показал Codex, но и у него остались незакрытые JWT-проблемы и отсутствие ревокации токенов.
Все три агента допустили одни и те же критические ошибки: Broken Access Control, хранение JWT-секретов в коде, обход аутентификации через WebSocket и IDOR (небезопасные прямые ссылки на объекты). Это не случайные баги — это системные паттерны, которые воспроизводятся независимо от модели. Параллельно инженер Anthropic Брайан Черни в июле 2025 года написал, что закрывает по 22–27 PR в день, каждый из которых написан Claude полностью, без ручных правок. Сочетание этих двух фактов и формирует проблему: скорость генерации кода растёт, а контроль качества за ней не успевает.
| Класс уязвимости | Уровень | Кто допустил |
|---|---|---|
| Broken Access Control | Высокий | Все три агента |
| Hardcoded JWT secrets | Высокий | Все три агента |
| WebSocket Auth Bypass | Высокий | Все три агента |
| IDOR | Высокий | Все три агента |
| User Enumeration | Средний | Все три агента |
| XSS | Средний | Gemini + все в отдельных случаях |
| Race Conditions (TOCTOU) | Средний | Преимущественно Gemini |
Автор материала на Habr предлагает конкретный ответ: выстроить DevSecOps-пайплайн поверх LLM-проекта, а не вместо него. Центральный элемент — Quality Gate, набор правил, которые код обязан пройти перед продолжением пайплайна. В SonarQube Cloud стандартный профиль Sonar way требует рейтинга A по безопасности, надёжности и поддерживаемости, покрытие тестами не ниже 80% и долю дублирующегося кода не выше 3%. Если хотя бы одно условие не выполнено, GitHub Actions останавливает процесс: build не запускается, деплой не происходит.
Все три агента допустили Broken Access Control, Hardcoded JWT secrets, WebSocket Auth Bypass и IDOR
Ключевой архитектурный выбор — разделение ролей между моделями. Claude Sonnet 4.5 пишет код, Claude Sonnet 4.6 исправляет уязвимости по отчёту сканера. Это не просто разные версии одной модели — по качеству они различаются. Важнее другое: модель работает не «на глаз», а поверх конкретного списка проблем от инструмента. SonarQube указывает файл, строку, тип уязвимости и уровень критичности — модель получает структурированный контекст, а не весь кодовый репозиторий целиком. Такой подход снижает риск того, что модель «согласится» с собственным кодом вместо того, чтобы его исправить.
Практическая разница между автоматическим анализом SonarQube и интеграцией через GitHub Actions принципиальна. Автоматический режим работает асинхронно: если между пушем и завершением анализа проходит минута, деплой уйдёт вперёд. GitHub Actions выстраивает жёсткую цепочку: push → sonarqube job → build → deploy, где каждый следующий шаг ждёт успеха предыдущего. При провале Quality Gate в логах появляется ERROR QUALITY GATE STATUS: FAILED с кодом выхода 3 и ссылкой на дашборд с конкретными проблемами. Для проектов, где безопасность критична, это единственный рабочий вариант.
Первый скан реального проекта Opensophy Hub — статической платформы для документации, написанной преимущественно через LLM, — выдал 234 проблемы. Это типичный результат для вайбкод-проекта без предварительных проверок. Следующие части серии разбирают, как систематически сокращать этот список: через Claude 4.6 для исправлений и Semgrep как второй инструмент анализа, который расходится с SonarQube в оценке части проблем.
