SAST, SCA, secret scanning и AI code review: что ловит каждый слой — и почему ни один не закрывает риск AI-сгенерированных изменений

Сравнение инструментов без маркетинговой воды: реальные цифры детектирования, слепые зоны и то, почему сумма четырёх слоёв всё ещё оставляет пробелы именно там, где AI генерирует код быстрее всего

Зачем эта тема сейчас

Если в 2022 году AppSec-команда занималась пятью PR в день, то в 2025-м та же команда работает с двадцатью — и большинство из них содержат код, который никто не писал вручную строка за строкой. По данным GitHub, 97% разработчиков используют AI-инструменты хотя бы раз в работе [1]. Claude Code в одиночку добавил больше 30 миллиардов строк в публичные репозитории за последние 90 дней [2].

При этом контроль не вырос пропорционально. Команды пользуются теми же SAST/SCA/secret-scanning пайплайнами, что и раньше. Инструменты не стали плохими — они просто были спроектированы под другую угрозовую поверхность.

Исследователи из Georgia Tech SSLab запустили проект «Vibe Security Radar»: отслеживать CVE, напрямую связанные с AI-авторством кода. К марту 2026 года они насчитали 74 подтверждённые CVE из 43 849 проанализированных advisory [2]. Ханцин Чжао, основатель проекта, сразу предупредил: «это нижняя граница, а не соотношение» — большинство случаев просто не атрибутируется. Это не означает, что AI-код безопаснее человеческого. Это означает, что инструменты обнаружения пока не настроены на AI-специфические паттерны.

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

Слой 1. SAST: что внутри вашего кода

Как работает

SAST (Static Application Security Testing) анализирует исходный код, байткод или бинарники без запуска приложения. Инструмент строит граф потока данных, ищет taint-пути от источника ввода до потенциально опасного sink-а, матчит паттерны по базе правил. Это позволяет ловить SQL-инъекции, XSS, command injection, небезопасную работу с криптографией, hardcoded credentials в коде и сотни других классов уязвимостей на ранней стадии — до деплоя.

Ключевые инструменты в 2025-2026 году: Semgrep (легковесный, с открытыми правилами, хорошо работает в CI), Checkmarx One (энтерпрайз с широким language coverage), Sonar/SonarQube (начинался как code quality, дорос до SAST), CodeQL (GitHub, сильный taint-analysis), Veracode Static Analysis, Fortify (OpenText). Каждый инструмент имеет своё сильное место по языкам и типам уязвимостей [1].

Реальные цифры, не маркетинг

Академический бенчмарк EASE 2024 (28-я конференция ACM по оценке ПО) протестировал четыре SAST-инструмента против 170 вручную верифицированных коммитов с реальными уязвимостями в Java-коде. Все четыре инструмента вместе поймали 38,8% от реальных уязвимостей. Это означает, что 61,2% прошли незамеченными при настройках по умолчанию [3].

Другая точка данных: Ghost Security в июне 2025 просканировала почти 3 000 открытых репозиториев на Go, Python и PHP традиционными SAST-инструментами. Результат: более 91% помеченных уязвимостей оказались false positives [4].

Вместе эти два числа создают неудобную картину: SAST одновременно шумит (большинство срабатываний — ложные) и молчит (большинство реальных проблем пропускает). Veracode в своём отчёте о false positive rates констатирует диапазон 15-60% в реальных деплоях, один из опросов StackHawk нашёл, что 98% SAST-находок оказываются неэксплуатируемыми при проверке в runtime [3].

Парадокс дизайна инструмента: разработчики SAST-инструментов исторически настраивают баланс в сторону «больше срабатываний», потому что это выигрышная стратегия в sales-ситуации. Клиент видит большой список находок и считает инструмент мощным — не проверяя, сколько из них реально [5].

Что SAST не видит принципиально

• Уязвимости в зависимостях. SAST не запрашивает базы CVE, не знает, какую версию lodash вы используете.
• Runtime-поведение: бизнес-логика, которая корректна в коде, но неверна в контексте системы.
• Конфигурации, инфраструктурный код, IaC — частично, зависит от инструмента.
• Уязвимости, которых нет в базе правил. AI-сгенерированный код создаёт нетипичные паттерны, которые правила не покрывают.

AI-специфическая слепая зона SAST

Veracode протестировала более 100 LLM на 80 задачах кодирования и нашла, что 45% генерируемого кода содержит критические уязвимости [6]. Apiiro исследовала Fortune 50: уязвимости класса CVSS 7.0+ встречаются в AI-коде в 2,5 раза чаще, путей для privilege escalation — на 322% больше [7]. CodeRabbit проанализировал 470 pull request: AI-authored код содержит в среднем 10,83 issue против 6,45 в human-authored [8].

SAST может поймать часть этого — там, где паттерн известен и правило написано. Но AI-специфические классы уязвимостей — некорректные проверки авторизации в multi-role системах, отсутствие defensive programming constructs, subtle logic flaws — в базы правил попадают с задержкой, если попадают вообще [9].

Слой 2. SCA: что приехало вместе с зависимостями

Как работает

SCA (Software Composition Analysis) анализирует состав зависимостей: прямых, транзитивных, в контейнерных образах. Инструмент строит граф зависимостей, сопоставляет с базами CVE (NVD, GitHub Advisory Database, OSV), проверяет лицензионную совместимость, генерирует SBOM (Software Bill of Materials). Основные инструменты: Snyk Open Source, Dependabot, OWASP Dependency-Check, Black Duck, Mend.io, Sonatype Nexus, Trivy.

Сильная сторона SCA — скорость деплоя (почти zero config для базового сценария) и точность: false positive rate в реальных деплоях составляет 2-10% против 15-60% у SAST [3]. Ремедиация прозрачная: обновить зависимость. Зона покрытия критична — по оценкам Veracode 2025, 70% критического security debt приходит из стороннего кода [3].

Проблема с базами данных

С февраля 2024 года NVD (National Vulnerability Database) резко замедлила обработку новых уязвимостей. К сентябрю 2024-го 72,4% CVE не были проанализированы [3]. Инструменты, полагающиеся только на NVD, имеют материальный пробел в покрытии. GitHub Advisory Database обрабатывает advisory с медианой 2 дня от патча до публикации, против 28 дней у NVD [3]. Это важный факт при выборе SCA-инструмента.

Reachability analysis — ключевое достижение последних лет: вместо того чтобы флагать каждый уязвимый пакет, инструмент проверяет, вызывается ли уязвимая функция из вашего кода реально. Вендоры заявляют снижение false positives на 80-95%. На практике: для статически типизированных языков (Java, .NET) это работает зрело, для динамических (JavaScript, Python) остаётся сложной задачей из-за dynamic dispatch и рефлексии [3].

Slopsquatting: угроза, которую SCA не покрывает

Это центральный AI-специфический риск для SCA. Исследователи из трёх американских университетов (University of Texas at San Antonio, Virginia Tech, University of Oklahoma) проанализировали 576 000 образцов кода от 16 разных LLM. Почти 20% рекомендованных пакетов не существовало ни в одном публичном реестре [10]. Среди галлюцинированных пакетов — 43% повторялись при повторных запросах, что делает их предсказуемыми мишенями для атакующих [11].

Механика slopsquatting: атакующий отслеживает, какие несуществующие имена пакетов AI-инструменты называют чаще всего, регистрирует пакет с этим именем в PyPI или npm и загружает вредоносный код. Установка не падает с ошибкой — пакет существует и работает, но делает не то [11].

SCA не знает об этом. Инструмент проверяет известные CVE в известных пакетах. Свежезарегистрированный вредоносный пакет без CVE проходит через SCA незамеченным — до тех пор, пока кто-то не напишет rule для него.

Слой 3. Secret scanning: ключи в коде

Как работает

Secret scanning ищет в коде и git-истории строки, соответствующие паттернам секретов: AWS access keys (всегда начинаются с AKIA), API-токены, приватные ключи SSH, пароли базы данных, OAuth-токены. Три базовые техники: pattern matching по известным форматам, энтропийный анализ (высокая случайность строки — признак токена), ML-классификация для нетипичных форматов [12].

Основные инструменты: GitGuardian (покрывает 550+ типов секретов, самое широко установленное приложение на GitHub), TruffleHog, Gitleaks, Detect Secrets (open-source от Yelp), GitHub Secret Scanning / GitHub Push Protection, GitLab Secret Push Protection.

Масштаб кризиса: реальные данные

GitGuardian State of Secrets Sprawl 2026 проанализировал публичный GitHub за 2025 год: 29 миллионов новых hardcoded secrets — на 34% больше, чем в 2024-м, наибольший однолетний прирост в истории наблюдений [13]. Для контекста: с 2021 года утечки секретов выросли на 152%, тогда как активная база разработчиков GitHub — на 98% [13]. Секреты растут быстрее людей.

Данные по AI-кодингу специфически: коммиты с Claude Code текут с частотой ~3,2% — вдвое выше базового уровня по всему GitHub [13]. Репозитории с AI-ассистентами фиксировали на 40% больше утечек секретов, чем без них [14].

Критическая деталь: 70% секретов, утёкших в 2022 году, остаются активными до сих пор [14]. Утечка — это не событие, это постоянно открытое окно.

Где secret scanning не помогает

58% утечек составляют generic secrets — пароли баз данных, строки соединений, кастомные токены без стандартного формата [14]. Pattern matching их пропускает или фиксирует с высоким false positive rate. GitHub Push Protection борется именно с этой категорией.

Главный вывод отчёта 2026: 28% инцидентов с секретами в 2025 году возникли полностью за пределами source code — в Slack, Jira, Confluence [13]. В 6,1% Jira-тикетов были обнаружены утечки credentials [14]. Если вы сканируете только код, вы видите три четверти поверхности.

Новая угроза: MCP (Model Context Protocol) — способ подключения AI-агентов к внешним инструментам. GitGuardian нашёл 24 008 уникальных секретов в MCP-конфигурационных файлах на публичном GitHub в 2025 году, из них 2 117 верифицированы как валидные [13].

Слой 4. AI code review: понимание намерения

Как работает

AI code review (CodeRabbit, GitHub Copilot Code Review, Cursor BugBot, Graphite Agent, Greptile) использует LLM для анализа diff pull request в контексте репозитория. В отличие от SAST, который работает по правилам, LLM-ревьювер может понять намерение, объяснить проблему, предложить исправление, задать вопрос. Он видит, что код делает, а не только как он написан.

Реальные результаты: команды с Copilot Code Review сообщают о сокращении времени от открытия PR до первого review comment на 35% и общего цикла ревью — на 25% [15]. По совокупным данным enterprise case studies — снижение post-merge defects на 15-30% при использовании AI review в связке с SAST [15].

Что AI code review не может

AI code reviewer не знает вашего бизнеса. Он может верифицировать математическую корректность расчёта скидки, но не может знать, что политика скидок изменилась в прошлом квартале, или что именно этот endpoint не должен возвращать данные анонимным пользователям, хотя код это допускает [15].

Конкретный пример из Cloud Security Alliance: AI-ассистент может написать проверку авторизации if user.role == "admin" вместо if "admin" in user.roles. Код работает для пользователей с одной ролью, но ломается в системах с множественными ролями, давая избыточный доступ [16]. Это не паттерн-матч-ошибка — это семантическая ошибка в контексте системы. Никакой SAST её не поймает. AI code reviewer без знания domain-правил тоже не поймает.

Другая принципиальная проблема: контекстное окно LLM конечно. При итеративной разработке с AI-ассистентами безопасные ограничения, заданные в начале сессии, могут «вымываться» по мере её роста. Исследование 2025 года показало: в итеративных AI-сессиях уязвимости накапливаются, а не убываются — security-промпты из начала сессии dilute по мере её удлинения [17].

AI code review также не защищён от ситуации, когда один AI ревьюит другой AI без критического взгляда. Галлюцинированные пакеты иногда валидируются AI-ревьювером как «выглядят легитимно» — потому что тот обучен на том же корпусе кода [11].

Почему сумма четырёх слоёв не равна покрытию AI-риска

Эта часть — ключевая. Каждый из четырёх инструментов создавался под определённую угрозовую модель:

SAST создавался для мира, где разработчик пишет код вручную, а уязвимость — это синтаксическая или структурная ошибка. SCA создавался для мира, где пакет приходит из реестра с известной историей. Secret scanning создавался для мира, где секрет в коде — это человеческая небрежность, повторяющаяся по известным паттернам. AI code review создавался для ускорения цикла ревью.

Ни один из них не создавался для мира, где:

1. Пакет может быть рекомендован AI, не существовать в реестре и появиться в реестре спустя несколько часов — уже вредоносным.
2. Privilege escalation path может быть правильно написан синтаксически, не содержать CVE, не быть секретом — но создавать системный риск в контексте конкретной архитектуры.
3. Конфигурация CI/CD, написанная AI, может открывать широкий CORS, fallback-credentials или debug-режим — без единого сигнала ни от SAST, ни от SCA.
4. Каждый из четырёх инструментов смотрит в свой срез данных. Никто не смотрит на изменение целиком: diff кода + новые зависимости + изменения конфигурации + контекст релиза — одновременно.

Исследование Konvu 2026 суммирует: SAST не говорит о CVE в зависимостях, SCA не говорит о SQL-инъекции в вашем коде, ни один не видит полную картину [3]. OX Security дополняет: статические инструменты работают в silos — каждый смотрит узкий срез пайплайна, но никто не соединяет код, артефакты, API и runtime-экспозицию в единый граф [18].

Это проблема архитектуры инструментального стека, а не качества отдельных инструментов.

Практическая часть: что проверять и где

До merge — чек-лист для PR с AI-сгенерированным кодом

Код и логика:

• Есть ли уязвимости, которые SAST поймал с высокой уверенностью (taint-пути, не dead code)?
• Есть ли business logic flaws: некорректные проверки ролей, отсутствующие null-checks, fallback на небезопасное поведение?
• Есть ли паттерны из OWASP Top 10 — injection, broken access control, security misconfiguration?
• Для AI-authored кода отдельно: authentication, authorization и cryptography требуют human review (не AI review) как обязательного шага.

Зависимости:

• Все ли новые пакеты существуют в реестре до момента их рекомендации?
• Нет ли свежезарегистрированных пакетов с коротким возрастом (признак slopsquatting)?
• Проверены ли транзитивные зависимости, а не только прямые?
• Какой advisory database использует ваш SCA? NVD (задержка до 28 дней) или GitHub/OSV (медиана 2 дня)?

Секреты и конфигурация:

• Нет ли hardcoded secrets, даже в «тестовых» файлах?
• Нет ли debug-флагов, fallback-endpoints или overly broad CORS в конфигах?
• Проверены ли IaC-файлы, CI/CD-конфиги, docker-compose — не только application code?

Перед релизом — decision framework

Не каждая находка блокирует релиз. Вопросы для быстрого решения:

• Что реально эксплуатируемо в этом контексте (reachability analysis, а не просто CVE score)?
• Есть ли уязвимость в коде, который деплоится в этом релизе, или только в неиспользуемой ветке?
• Secrets: любой leak — блокирующий, ротация критична до выхода.
• Business logic flaws в authentication/authorization — блокирующие.
• SCA: критические CVE в реально вызываемом коде — блокирующие; CVE в пакете без reachability — приоритет следующего спринта.

Типовые ошибки при настройке стека

• Запуск SAST с дефолтными правилами без тюнинга. Результат: 91% false positive, команда отключает alert или игнорирует queue.
• Игнорирование транзитивных зависимостей в SCA. Большинство supply chain атак идут именно через них.
• Secret scanning только на public commit, не на private. В private репозиториях секреты встречаются в 8 раз чаще [14].
• Считать, что AI code review = security review. AI-ревьювер ускоряет цикл, но не знает domain-логику и угрозовую модель.
• 16+ инструментов безопасности в стеке. Команды с таким количеством инструментов показывают 50% уровень burnout против 17% у команд с 1-5 инструментами [3].

Кейсы и сценарии

Сценарий 1: AI добавляет зависимость, которой не существовало

Разработчик просит AI-ассистента добавить удобную библиотеку для работы с JWT. Ассистент предлагает jwt-validate-plus. Пакет не существует. Разработчик пробует pip install — ошибка, просит ещё раз. На второй попытке ассистент предлагает то же имя. Тем временем атакующий зарегистрировал этот пакет с вредоносным кодом два часа назад. SCA проверяет пакет — CVE нет, пакет молодой, но это не сигнал для большинства инструментов.

Что поймает: ничего из классического стека. Что нужно: проверка возраста пакета и его аномальной «свежести» в момент добавления.

Сценарий 2: AI переписывает middleware авторизации

В рамках рефакторинга AI-ассистент переписывает middleware, проверяющий роли. Новая версия синтаксически корректна, тесты проходят. Но проверка user.role == "admin" заменила старую "admin" in user.roles. В системе есть пользователи с двумя ролями. После деплоя они получают admin-доступ в части интерфейса.

Что поймает: SAST — нет (код синтаксически корректен, паттерн не в базе правил). SCA — нет. AI code reviewer — возможно, если знает domain-контекст; скорее нет. Secret scanning — нет.

Что нужно: контекстный анализ изменения с пониманием, что функция авторизации была изменена и требует углублённого ревью.

Сценарий 3: CI/CD конфиг с debug-настройками

AI помогает написать docker-compose для staging-окружения. В конфиге появляется FLASK_ENV=development, широкий CORS * и комментарий # TODO: restrict before prod. PR мерджится быстро — это же только staging. Через два квартала этот конфиг копируется в prod-деплой.

Что поймает: SAST (если настроен на IaC/конфиги, не всегда по умолчанию). Secret scanning — если видит literal secret, но FLASK_ENV=development — не секрет. AI code reviewer — возможно заметит TODO.

Что нужно: анализ конфигурационного изменения в контексте целевого окружения деплоя.

Будущее: куда движется стек

AI-дополненный SAST уже меняет соотношение. IRIS framework (ICLR 2025) обнаружил 55 уязвимостей против 27 у CodeQL на одном и том же датасете. LLM-Driven SAST-Genius снизил false positive с 225 до 20 на тестовом наборе [19]. Это не «AI заменяет SAST», это «AI помогает тюнить и приоритизировать находки SAST».

Reachability analysis в SCA становится стандартом: Semgrep, Snyk, Xygeni — все делают ставку на «смотри не на пакет, а на то, вызывается ли уязвимая функция» [20]. Это меняет характер шума — но не убирает проблему с новыми и галлюцинированными пакетами.

Non-Human Identity (NHI) governance становится отдельным направлением: AI-агенты работают с credentials, MCP-конфиги хранят токены, CI/CD runners накапливают ключи. GitGuardian 2026 констатирует: 59% компрометированных машин в их датасете — CI/CD runners, не персональные ноутбуки [13]. Это системная проблема, которую классический secret scanning покрывает частично.

Более значимый тренд: консолидация инструментов в ASPM-платформы (Application Security Posture Management). Но консолидация решает проблему управления стеком, а не проблему слепых зон при анализе конкретного AI-сгенерированного изменения.

Дополнительный слой: контроль конкретного изменения

Описанные выше стеки хорошо работают для массового сканирования репозитория. Слабое место — анализ конкретного PR в его полноте: что изменилось в коде, какие зависимости добавились, что поменялось в конфигах, каков контекст релиза.

Именно здесь работает HighVibe: не как замена SAST/SCA/secret scanning, а как дополнительный слой контроля до merge и релиза. Инструмент смотрит на конкретное изменение — diff кода, новые и обновлённые зависимости, конфигурационные файлы, контекст выпуска — и даёт короткий, понятный сигнал команде. Не длинный отчёт, а практический ответ: можно ли безопасно принять именно это изменение прямо сейчас.

Это особенно важно там, где классические инструменты молчат: бизнес-логические изменения в auth-коде, свежие зависимости без CVE, конфигурации с debug-режимом. И особенно актуально в AI-эпоху, когда PR приходит быстро, дифы длинные, а читают их не до конца.

Подробнее о подходе: highvibe.dev

Заключение: что делать дальше

Инструменты не виноваты. SAST, SCA, secret scanning и AI code review — рабочие слои, каждый из которых закрывает реальный класс рисков. Проблема в том, что AI-кодинг изменил характер входящего потока: больше кода, быстрее, с новыми классами уязвимостей и новыми векторами supply chain.

Три операционных вывода:

Первый. Тюнинг важнее количества инструментов. SAST с дефолтными правилами и 91% false positive хуже, чем правильно настроенный Semgrep с custom-правилами под ваш стек. Потратьте время на снижение шума — иначе команда будет игнорировать queue.

Второй. Для AI-сгенерированного кода нужен отдельный фокус ревью. Authentication, authorization, cryptography, payment processing — эти зоны требуют mandatory human review, не только автоматики. AI code review ускоряет цикл, но не заменяет доменный контекст.

Третий. Смотрите на изменение, а не только на репозиторий. Конкретный PR несёт конкретный риск. Риск виден в diff кода + новых зависимостях + конфигах + контексте деплоя одновременно. Инструментальный стек, который смотрит на каждый из этих слоёв отдельно, оставляет пробелы именно в этой связке.

AI-кодинг — не проблема, которую нужно запрещать. Это возможность, которую нужно контролировать на правильном уровне детализации.

Источники

[1] OX Security — Top 10 SAST Tools in 2026 — https://www.ox.security/blog/static-application-security-sast-tools/

[2] The Register — AI coding assistant not more secure — https://www.theregister.com/2026/03/26/ai_coding_assistant_not_more_secure/

[3] Konvu — SCA vs SAST 2026: What Each Tool Finds, Misses, and Costs — https://konvu.com/compare/sca-vs-sast

[4] Help Net Security — 91% noise: A look at what's wrong with traditional SAST tools — https://www.helpnetsecurity.com/2025/06/19/traditional-sast-tools/

[5] Mend.io — Determining A Benchmark Of False Positives With SAST Tools — https://www.mend.io/blog/benchmark-of-false-positives/

[6] Veracode — AI-Generated Code Security Risks — https://www.veracode.com/blog/ai-generated-code-security-risks/

[7] SoftwareSeni — AI-Generated Code Risks: Why Vulnerabilities Increase 2.74x — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[8] Help Net Security — AI code looks fine until the review starts — https://www.helpnetsecurity.com/2025/12/23/coderabbit-ai-assisted-pull-requests-report/

[9] Cloud Security Alliance — Understanding Security Risks in AI-Generated Code — https://cloudsecurityalliance.org/blog/2025/07/09/understanding-security-risks-in-ai-generated-code

[10] DevOps.com — AI-Generated Code Packages Can Lead to 'Slopsquatting' Threat — https://devops.com/ai-generated-code-packages-can-lead-to-slopsquatting-threat-2/

[11] The Register — AI code suggestions sabotage software supply chain — https://www.theregister.com/2025/04/12/ai_code_suggestions_sabotage_supply_chain/

[12] GitGuardian Blog — Secret Scanning Tools 2026 — https://blog.gitguardian.com/secret-scanning-tools/

[13] GitGuardian — State of Secrets Sprawl 2026 PR — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026-pr/

[14] GitGuardian — State of Secrets Sprawl 2025 PR — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2025-pr/

[15] Cozcore — AI-Powered Code Review: How LLMs Are Changing Software Quality — https://www.cozcore.com/blog/ai-powered-code-review

[16] Cloud Security Alliance — Understanding Security Risks in AI-Generated Code — https://cloudsecurityalliance.org/blog/2025/07/09/understanding-security-risks-in-ai-generated-code

[17] arXiv — Security Degradation in Iterative AI Code Generation — https://arxiv.org/pdf/2506.11022

[18] OX Security — AI Attacks Are Outpacing Static Security Tools — https://www.ox.security/blog/ai-attacks-are-outpacing-static-security-tools/

[19] Diffray — LLM Hallucinations in AI Code Review — https://diffray.ai/blog/llm-hallucinations-code-review/

[20] Semgrep — AI-assisted SAST, SCA and Secrets Detection — https://semgrep.dev/