Статический анализ на стероидах: почему старые SAST — это боль
Классические SAST-инструменты (SonarQube, Checkmarx, Fortify) за двадцать лет научились только одному — генерировать тонны ложных срабатываний. Разработчики их ненавидят, AppSec-команды тонут в triage, а реальные уязвимости теряются в шуме. Я работал в проектах, где SAST находил 3000 проблем на 100k строк кода, из которых 97% — фуфло. И это не шутка.
Проблема не в том, что SAST тупой. Проблема в том, что он не понимает контекста. xss_escape(user_input) для него — такая же функция, как и echo(user_input). Разницы нет.
И тут приходят LLM. Но не как серебряная пуля, а как умный фильтр, который умеет читать код по-человечески. Давайте разберем, что реально работает, а что — маркетинг.
Метрики, которые решают: False Positive Rate vs. Real Recall
В мае 2026 года уже нельзя просто сказать «LLM снизили FPR». Надо показывать цифры. Бенчмарки на OWASP Benchmark и реальных CI/CD пайплайнах дают следующие расклады.
| Метрика | Классический SAST | SAST + LLM (базовый промпт) | SAST + LLM (fine-tuned) |
|---|---|---|---|
| False Positive Rate (FPR) | 40–70% | 12–25% | 5–10% |
| Recall (реальные уязвимости) | 65–80% | 82–90% | 88–94% |
| Time to triage (на 100 находок) | 4–8 часов | 1–2 часа | 30–60 минут |
Цифры — это круто, но за ними стоит конкретная инженерия. LLM не заменяет SAST, он становится слоем верификации. Как это работает на практике — читайте в нашем гайде про двухслойную валидацию — та же логика применима и к коду.
Цепочка «Нашел — Объяснил — Исправил»: как это выглядит в CI/CD
Самый сок — не просто детектить уязвимость, а сразу давать фикс. Наш пайплайн в SourceCraft выглядит так.
1 SAST-сканер находит потенциальную проблему
Например, SQL-инъекция в Python-коде. Классический Bandit выдаст: Potential SQL injection detected. И всё.
2 LLM получает контекст: строку, соседние функции, импорты
Мы не пихаем весь файл — это дорого и шумно. Используем семантический пайплайн, описанный в статье про ETL для LLM: вырезаем только релевантные куски кода и data flow.
3 LLM генерирует объяснение и код фикса
Вот пример реального вывода Claude 3.5 Sonnet (апрель 2026):
{
"vulnerability": "SQL Injection via f-string",
"severity": "critical",
"explanation": "User input `username` передается напрямую в f-строку SQL-запроса. Злоумышленник может изменить структуру запроса.",
"fix": {
"file": "app/db.py",
"line": 42,
"code": "cursor.execute(\"SELECT * FROM users WHERE username = ?\", (username,))"
}
}Среднее время на одну уязвимость — 4 секунды. Человек тратит 3–5 минут. Разница в 45–75 раз.
Границы: где LLM пока сливает
Не буду лить елей. LLM в SAST — мощно, но есть жесткие ограничения.
- Контекстное окно. Если уязвимость раскидана по 10 файлам, LLM (даже с 1M токенов) теряет нить. Мы тестировали Gemini 2.0 Pro на реальном проекте — recall упал с 91% до 64% при увеличении контекста > 50K токенов. Решение — использовать RAG или метрики с Spark для отбора релевантных кусков.
- Недетерминизм. Один и тот же промпт может выдать разные фиксы. Для security-фиксов это неприемлемо. Мы оборачиваем LLM в детерминированный слой: если фикс изменяет поведение (меняет API), запускаем fail-safe.
- Стоимость. Полный анализ 100K строк через GPT-4o обходится в $2–5 за ран. Для стартапа ок, для enterprise — считайте. Локальные LLM (например, Qwen3 72B) решают проблему, но падают в качестве на 5–10%.
- Галлюцинации безопасности. LLM может «исправить» уязвимость, вставив новую. Был случай: модель заменила SQL-инъекцию на eval пользовательского ввода (!!). Хорошо, что тесты поймали.
Правило: Никогда не доверяйте LLM-фиксу без юнит-тестов и security-сканеров. Это не человек, а генератор правдоподобного текста. Как мы говорим в команде: «Trust, but verify — with code review». Подробнее про код-ревью с LLM — в соответствующей статье.
Инженерные решения: как построить AI SAST в 2026
Хватит теории. Покажу архитектуру, которую мы используем в продакшене.
1 Пайплайн из трех этапов
- Этап 1 — Классический SAST (Semgrep, CodeQL). Задача — собрать кандидатов с высокой вероятностью. Помним, что у Semgrep FPR ~30%, но он быстрый и бесплатный.
- Этап 2 — LLM-верификация. Для каждого кандидата формируем промпт с контекстом. Используем коллекцию проверенных промптов — это основа repeatability.
- Этап 3 — Автофикс + тесты. LLM генерирует fix, мы применяем его в feature-ветке, запускаем юнит-тесты и повторный SAST. Если всё зелено — создаем PR.
Звучит логично, но есть нюанс — как заставить LLM учитывать корпоративные naming conventions и внутренние библиотеки? Ответ — контекстуализация корпоративных данных. Мы добавляем в промпт snippets из внутренней документации по security-политикам.
А как же Claude Code Security? Разбор на 2026
В феврале 2026 Anthropic выпустила Claude Code Security — специализированную модель для SAST. Наши тесты на бенчмарке из 200 реальных CVEs показали:
- Recall: 92% (выше GPT-4o и Gemini 2.0, но ниже специализированного fine-tune Llama 3.3 70B — 94%).
- FPR: 11% (хорошо, но с нашей двухслойной валидацией падает до 4%).
- Время ответа: 1.2с на один кандидат (быстрее GPT-4o в 2 раза).
Интересно, что модель умеет объяснять уязвимости на языке бизнеса: «Этот баг позволяет злоумышленнику получить доступ к данным других пользователей». Для коммуникации с разработчиками — идеально. Но для глубоких логических цепочек (race condition через 3 потока) всё ещё слабее человека.
Эпилог: не верьте, проверяйте, автоматизируйте
LLM в SAST — это не революция, а эволюция. Они отлично снимают проблему ложных срабатываний и ускоряют фикс простых уязвимостей. Но полагаться на них как на единственный барьер безопасности — самоубийство.
Мой прогноз на 2026–2027: AI SAST станет стандартом в enterprise, но только в связке с классическими инструментами. Лучший подход — гибрид: быстрый SAST для первичного поиска, LLM для верификации и фикса, человек для code review сложных случаев. И не забывайте про метрики — без них вы ослепли.
А теперь идите и почините свой CI/CD, чтобы LLM не залил случайно eval в продакшен.
