Двадцать лет ада
Разработчики врут, когда говорят, что любят SAST. Они его терпят. Потому что иначе AppSec-команда не пустит релиз. Классические инструменты — SonarQube, Checkmarx, Fortify — за двадцать лет научились одному: генерировать тонны ложных срабатываний. 3000 проблем на 100k строк кода, из которых 97% — фуфло. Я серьёзно. Разработчики тратят часы на triage, реальные уязвимости тонут в шуме, а продуктовая фича стоит на паузе. И это норма? Нет, это боль.
Проклятие SAST в том, что он не понимает контекста. xss_escape(user_input) для него — то же самое, что echo(user_input). Разницы ноль.
Врываются LLM. Но не как серебряная пуля
В мае 2026 года уже нельзя просто сказать «LLM снизили FPR». Надо показывать цифры. И они есть. Мы провели бенчмарки на OWASP Benchmark и реальных CI/CD пайплайнах. Результаты — в таблице ниже. Спойлер: fine-tuned модель режет ложные срабатывания в 10 раз по сравнению с классикой.
| Метрика | Классический SAST | SAST + LLM (базовый промпт) | SAST + LLM (fine-tuned) |
|---|---|---|---|
| False Positive Rate | 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, он становится слоем верификации. Эту же логику мы уже описали в архитектуре двухслойной валидации — принцип тот же, только вместо документов — код.
Claude Code Security: хайп или прорыв?
В начале 2026 года Anthropic выпустила Claude Code Security — модуль, который встраивается прямо в CI/CD. Он не просто подсвечивает уязвимость, а объясняет её на естественном языке и предлагает патч. Разработчики в восторге: triage превращается в чтение понятных комментариев. Хайп вокруг этой фичи поднял волну интереса к AI SAST. И это справедливо — но только если не забывать, что базовая модель без дообучения на вашем коде будет галлюцинировать точно так же, как и любой LLM. Кстати, о том, как защитить код, написанный самими LLM, мы писали в отдельной статье.
Цепочка «Нашел — Объяснил — Исправил»
Самый сок AI SAST — не просто детектить, а сразу давать фикс. Пайплан выглядит так. SAST-сканер находит потенциальную проблему — например, SQL-инъекцию в Python. Классический Bandit выдаст «Potential SQL injection detected» — и всё. LLM получает контекст: строку, соседние функции, импорты. Не весь файл — это дорого и шумно. Используем семантический пайплайн, описанный в статье про ETL для LLM: вырезаем только релевантные куски кода. Модель пишет: «Используйте параметризованные запросы, вот пример патча». Разработчик нажимает «Accept», и уязвимость закрыта. Без отрыва от IDE.
Звучит как сказка? На практике — да, но есть нюанс. LLM может предложить патч, который не скомпилируется, или отрефакторить код так, что сломается логика. Поэтому финальное слово всегда за человеком. Хотя агентные системы отладки уже начинают брать на себя и эту работу.
Но не спешите хоронить старые инструменты
Лучшая стратегия сегодня — гибрид. Классический SAST как первый фильтр: быстро, дёшево, сердито. LLM как второй слой: умно, контекстно, но медленнее и дороже. И да — придётся обучать свою модель на вашем коде. Иначе LLM будет так же тупить, но уже с большим счётом за токены. В предыдущей статье мы разобрали метрики и инженерные решения — рекомендую углубиться, прежде чем внедрять AI SAST в продакшн.
И напоследок: не ведитесь на хайп. Claude Code Security крут, но он не панацея. Если ваш код — это легаси на COBOL, никакой LLM вам не поможет. Пока что. А через год — кто знает?
