SAST, SCA, Secret Scanning и Change-Based Review: почему четыре уровня лучше трёх

Когда сканеры работают — и почему этого всё равно недостаточно до merge

Почему тема актуальна прямо сейчас

2024–2025 годы переломили привычную логику AppSec. Не потому что появились принципиально новые классы уязвимостей, а потому что скорость изменений обогнала возможности контроля.

По данным опроса Kusari, 85% организаций уже внедрили AI-ассистенты для написания кода, но только 9% считают AI-driven AppSec-анализ обязательным [7]. Разрыв очевиден: инструменты генерации кода масштабировались быстрее, чем инструменты его проверки. Стек сканеров — SAST, SCA, secret scanning — при этом никуда не делся и работает. Проблема в другом: каждый из этих инструментов решает свою конкретную задачу, и между ними есть слепые зоны, которые становятся особенно опасными именно в момент merge и релиза.

Цель этой статьи — разобрать, что именно ловит каждый слой, где его границы, и почему команде дополнительно нужно решение по конкретному изменению — до того, как оно уходит в main или production.

Уровень первый: SAST — анализ вашего кода без его запуска

Что делает SAST

Static Application Security Testing анализирует исходный код или байткод приложения без его выполнения. Инструмент ищет паттерны потенциально опасного кода: SQL-инъекции, XSS, buffer overflow, небезопасная работа с вводом, insecure deserialization и другие CWE из каталога MITRE [8].

SAST работает на ранних стадиях SDLC — ещё до компиляции — и интегрируется в IDE, pre-commit hooks или CI-пайплайны. Именно это делает его ценным: разработчик получает сигнал, когда исправление дешевле всего.

Ключевые характеристики:

1. Анализирует только первый, «свой» код — не сторонние зависимости.
2. Работает с кодом статически, не видит runtime-поведение.
3. Требует настройки под конкретный стек: один язык — один конфигурируемый инстанс.
4. Может запускаться в любой момент, даже до того, как приложение функционально работает.

Что SAST не ловит

Исследование EASE 2024, протестировавшее четыре SAST-инструмента на 170 ручных коммитах с задокументированными уязвимостями в Java-коде, показало: все четыре инструмента вместе задетектировали лишь 38,8% реальных уязвимостей [9]. 61,2% прошли незамеченными.

Другое исследование 2024 года на 815 реальных уязвимых коммитах C/C++ нашло, что 22% известных уязвимостей не вызвали ни одного предупреждения SAST-инструмента, а среди тех коммитов, что всё-таки вызвали алерты, не менее 76% алертов оказались нерелевантны к реальной уязвимости [10].

SAST не видит:

1. Уязвимости в сторонних библиотеках и транзитивных зависимостях.
2. Runtime-уязвимости: то, что появляется только при исполнении.
3. Бизнес-логические ошибки: когда код технически верен, но semantically опасен.
4. Контекст окружения: где именно задеплоено приложение и какие данные оно обрабатывает.

Проблема ложных срабатываний

Ghost Security просканировала около 3000 open-source репозиториев на Go, Python и PHP. Результат: более 91% задетектированных уязвимостей оказались ложными срабатываниями [1]. NIST зафиксировал ложноположительный уровень SAST до 78% для Java [11]. Одна ревизия ложного срабатывания занимает в среднем 15–30 минут [12]. Когда сканер возвращает сотни алертов за CI-прогон, это не просто шум — это рациональный повод для команды перестать смотреть на очередь.

Уровень второй: SCA — анализ зависимостей и open-source компонентов

Что делает SCA

Software Composition Analysis анализирует сторонние компоненты: open-source библиотеки, пакеты из npm/PyPI/Maven, транзитивные зависимости. Инструмент сравнивает инвентарь компонентов с базами данных известных уязвимостей — NVD, OSV, GitHub Advisory Database — и сигнализирует о CVE.

По данным Synopsys 2024 OSSRA, 96% коммерческих кодовых баз содержат open-source компоненты [13]. 77–90% кода в типичном приложении — стороннее [14]. 70% критической security-задолженности приходится на код третьих сторон (Veracode, 2025) [14]. SCA закрывает слой, который SAST по определению не видит.

Ключевые характеристики:

1. Работает быстро — сканы занимают секунды независимо от размера проекта [2].
2. Малый процент ложных срабатываний (2–10% против 15–60% у SAST) [14].
3. Понятный путь ремедиации: обновить версию или заменить пакет.
4. Современные реализации включают reachability analysis — проверку того, реально ли вызывается уязвимая функция из вашего кода.

Где SCA не работает

Проблема с базой данных NVD. С февраля 2024 года NIST прекратил обогащение CVE: к сентябрю 2024-го 72,4% CVE не имели аналитики [4]. Инструменты, опирающиеся только на NVD, имеют материальный пробел в покрытии. GitHub Advisory Database обрабатывает advisory в среднем за 2 дня против 28 дней у NVD [14] — разница критическая при реагировании на свежие уязвимости.

Что SCA не ловит:

1. Zero-day малварь: если пакет скомпрометирован через взломанный аккаунт мейнтейнера, в базах ещё нет CVE. Атака на npm-пакеты chalk, debug и strip-ansi в сентябре 2025 года — 18 пакетов с суммарными 2,6 млрд скачиваний в неделю — не имела CVE в момент компрометации [15].
2. Dependency confusion: атаки на порядок разрешения пакетов между публичными и приватными реестрами.
3. Typosquatting, не внесённый в базы.
4. Бизнес-логические уязвимости в сторонних библиотеках.

Reachability analysis — значимый шаг вперёд, но для динамических языков (Python, JavaScript) она остаётся менее надёжной из-за динамической диспетчеризации, reflection и метапрограммирования [14].

Уровень третий: Secret Scanning — утечки ключей, токенов и учётных данных

Что делает secret scanning

Secret scanning ищет секреты, закодированные в репозитории: API-ключи, пароли, SSH-ключи, OAuth-токены, строки подключения к БД. Инструменты используют три техники: сопоставление с паттернами (AWS Access Key всегда начинается с «AKIA»), энтропийный анализ (высокая случайность строки указывает на ключ) и ML-модели для generic secrets.

Данные за 2025 год выглядят тревожно. В 2024 году на публичном GitHub было задетектировано 23,8 млн новых захардкоженных секретов — рост 25% год к году [3]. В 2025 году цифра выросла до 29 млн (+34% год к году) — крупнейший прирост за всю историю наблюдений GitGuardian [4]. 70% секретов, утёкших ещё в 2022 году, по-прежнему валидны [3].

Особенно значимо: 28% инцидентов с утечками секретов в 2025 году произошли не в репозиториях, а в инструментах для совместной работы — Slack, Jira, Confluence [4]. Сканирование только кода пропускает четверть экспозиции.

Влияние AI-кодинга

Коммиты с помощью AI-ассистентов утекают секреты примерно вдвое чаще, чем написанный вручную код. Конкретно: коммиты с использованием Claude Code — со скоростью ~3,2% против ~1,5% базовой [5]. Секреты, связанные с AI-сервисами, выросли на 81% год к году — до 1,275 млн задетектированных в 2025 году [4].

Где secret scanning не работает

1. 58% утечённых секретов — это «generic secrets»: неструктурированные пароли, private keys, кастомные токены, которые сложно детектировать без ложных срабатываний [3].
2. GitHub Push Protection эффективен для специфичных ключей (AWS, GCP), но слабо справляется с generic secrets [3].
3. 35% приватных репозиториев содержат хотя бы один plaintext-секрет — типичное заблуждение, что private == безопасно [16].
4. Секреты в Docker-образах: 18% отсканированных Docker-образов содержали секреты, и 15% из них были валидны [4].

Что объединяет три уровня: они смотрят на код, а не на изменение

SAST, SCA и secret scanning работают с репозиторием или пайплайном как с абстракцией. Каждый из них отвечает на вопрос «что есть в коде?» — и это правильные вопросы. Но у них есть общий структурный пробел:

Ни один из них не отвечает на вопрос «можно ли безопасно принять именно этот PR прямо сейчас?»

Это не недостаток конкретных инструментов — это граница класса инструментов. И этот пробел становится критичным по нескольким причинам.

Причина первая: AI-код меняет соотношение объёма и качества ревью

По данным отчёта ProjectDiscovery State of AppSec 2026, AI ускорил создание кода, но перенёс ограничение дальше по пайплайну: скорость генерации выросла, скорость верификации — нет [17]. 92,6% разработчиков используют AI-ассистенты хотя бы раз в месяц [48]. Количество неотревьюенного кода на PR растёт.

Veracode протестировала более 100 LLM и нашла: AI-сгенерированный код содержит в 2,74 раза больше уязвимостей, чем написанный вручную; процент неудач в тестах на безопасное кодирование — 45% [6]. CodeRabbit в декабре 2025 года проанализировал 470 open-source PR: AI-соавторский код имел примерно в 1,7 раза больше серьёзных проблем по сравнению с human-only кодом [6].

Georgia Tech Vibe Security Radar задетектировал 74 подтверждённых CVE, введённых именно AI-инструментами: 14 критических, 25 высоких. Среди них — command injection, authentication bypass, SSRF [51]. SAST и SCA задетектируют часть из них. Но ни один из этих инструментов не знает, что конкретный PR написан AI, что ревьюер дочитал до третьего файла из двадцати двух, что в этом релизе два новых npm-пакета появились незаметно в lock-файле.

Причина вторая: сканеры не учитывают релизный контекст

В AppSec принято разграничивать severity находки и риск принятия этой находки в production прямо сейчас. Сканеры работают с первым. Второе — это отдельная задача.

Postman описал свой опыт масштабирования AppSec-ревью: исходная модель рассматривала все релизы одинаково — незначительное изменение конфигурации и критичный редизайн аутентификации проходили через одинаковый процесс ревью. Это не масштабируется [23]. Решение — change-based риск-классификация: тип изменения, критичность сервиса, контекст релиза определяют, нужен ли мануальный ревью AppSec или автоматическое закрытие.

Причина третья: шум сканеров убивает сигнал

43% enterprise-компаний планировали сократить количество инструментов в 2025 году именно потому, что слишком много сканеров создают дублирующиеся находки, замедляют ремедиацию и выжигают команду [30]. По данным опроса AppSec 2025, команды с 16+ security-инструментами сообщают об уровне burnout 50% против 17% у команд с 1–5 инструментами [14].

Когда 91% алертов SAST — ложные срабатывания [1], а 88% «critical» CVE в SCA нерелевантны в вашем контексте (JFrog, 2025) [43], у команды есть рациональный стимул перестать смотреть на очередь. Это и есть alert fatigue — и именно в этот момент реальная находка тонет в шуме.

Change-Based Review: четвёртый уровень контроля

Change-based review — это не замена SAST/SCA/secret scanning. Это дополнительный слой контроля, который работает с конкретным diff, а не с репозиторием целиком.

Что такой слой умеет:

1. Анализировать конкретный набор изменений в контексте: что именно изменилось, в каком файле, в каком сервисе, насколько критичном.
2. Учитывать новые и обновлённые зависимости, появившиеся в данном PR — включая транзитивные.
3. Обращать внимание на изменения в конфигурации, CI/CD-файлах, миграциях, служебном коде — тех местах, которые ревьюеры читают хуже всего.
4. Учитывать релизный контекст: что выходит в этот релиз, насколько сервис критичен, какой blast radius у потенциального инцидента.
5. Давать короткий ответ: «можно принять», «проверь вот это» или «стоп — это блокирует выход».

Классический пример слепой зоны без такого слоя: pull request технически проходит SAST и SCA. Но в lock-файле тихо появился новый транзитивный пакет — через зависимость, которую SCA покрывает, но которая была обновлена три дня назад, advisory ещё нет, а код пакета содержит network call, которого не было раньше. Ни SAST, ни SCA, ни secret scanning этого не заметят.

Другой пример: конфигурационный файл с широким CORS, debug-флаги включены для тестирования и не отключены, hardcoded fallback-ключ в environment-файле — всё это может пройти через сканеры незамеченным, потому что каждый инструмент видит только свой слой.

Именно для таких случаев нужен слой, который смотрит на изменение целиком и задаёт вопрос с точки зрения безопасности конкретного merge или релиза.

Как четыре уровня работают вместе: decision framework

Вопрос не в том, какой инструмент выбрать. Вопрос в том, как выстроить контроль, который не создаёт избыточный шум и при этом не пропускает реальный риск.

Практический порядок уровней:

Уровень 1 — SAST: запускается на каждый коммит или PR. Ловит паттерны потенциально опасного кода в первом коде. Требует тонкой настройки правил под стек и регулярного аудита ложных срабатываний. Не стоит держать блокирующий gate по всем алертам SAST без предварительной настройки — это дорогая дорога к alert fatigue.

Уровень 2 — SCA: запускается при каждом изменении зависимостей, плюс непрерывный мониторинг по новым CVE. Для языков со зрелой reachability analysis (Java, .NET) — включить её, чтобы снизить объём нерелевантных алертов. Для Python/JS — понимать ограничение. Критически важно: не полагаться только на NVD, использовать GitHub Advisory Database или аналоги с быстрым временем обработки [14].

Уровень 3 — Secret scanning: на каждый коммит и PR, с pre-commit hooks для раннего перехвата. Для приватных репозиториев — обязательно: 35% содержат plaintext-секреты [16]. Для collaboration tools (Slack, Jira, Confluence) — отдельный контур, если обрабатываете чувствительные данные.

Уровень 4 — Change-based review: до merge и до release. Отвечает на вопрос, который другие три уровня не задают: «можно ли принять именно это изменение прямо сейчас, с учётом контекста?» Особенно важен при AI-generated коде, при изменениях в конфигурации, CI/CD и служебных файлах, при появлении новых или обновлённых зависимостей, перед релизом критичного сервиса.

Чек-лист: что проверять перед merge и релизом

Перед merge:

• Появились ли в этом PR новые зависимости в lock-файле — явные и транзитивные?
• Изменялись ли файлы конфигурации, CI/CD-скрипты, .env, миграции, IAM-политики?
• Есть ли в диффе authentication, authorization или cryptography-код? Если AI написал его — проверить вдвойне.
• Дочитан ли PR полностью, или ревьюер остановился на третьем файле из пятнадцати?
• Прошёл ли secret scan по этому коммиту, включая новые environment-файлы?

Перед релизом:

• Что из этого релиза является «net new» с точки зрения зависимостей и конфигурации?
• Есть ли в релизе debug-флаги, широкий CORS, temporar access-ключи?
• Критичность сервиса — насколько велик blast radius потенциального инцидента?
• Какой из алертов SAST/SCA реально блокирует этот релиз, а не просто числится в backlog?

Частые ошибки и как их избежать

Ошибка 1: «Всё прошло сканеры — значит, безопасно». Это подмена: «функционально работает» ≠ «безопасно для merge/release». Сканеры закрывают конкретные классы рисков. Риски на стыке классов, в конфигурации и в контексте релиза остаются за пределами их ответственности.

Ошибка 2: «Приватный репозиторий — значит, секреты в безопасности». 35% приватных репозиториев содержат хотя бы один plaintext-секрет [16]. Приватность канала не эквивалентна защищённости данных.

Ошибка 3: «Мы включили блокирующий gate по всем SAST-алертам». Если перед этим не была проведена тонкая настройка правил и аудит ложных срабатываний — команда получит поток бессмысленных блокировок и перестанет доверять gate. Правильная последовательность: наблюдение → тонкая настройка → мягкий gate → жёсткий gate для критичных паттернов.

Ошибка 4: «SCA закрыл все зависимости». SCA работает с известными CVE. Zero-day компрометации аккаунтов мейнтейнеров, dependency confusion, поведенческие аномалии пакетов (network calls, которых не было в предыдущей версии) — вне его области. Поведенческий анализ пакетов (Socket.dev и аналоги) — отдельная практика.

Ошибка 5: «AI написал — значит, сканеры точно проверят». AI-сгенерированный код проходит SAST и SCA так же, как любой другой. Проблема в том, что объём такого кода растёт быстрее, чем время ревью. Treat AI как untrusted contributor: всё, что вышло из AI в критичный модуль — проверяется как PR от неизвестного внешнего разработчика [47].

Кейс: что происходит без change-based review

Исходная модель AppSec-ревью в Postman — хороший задокументированный пример структурного пробела. AppSec нотифицировался через VAPT-тикет только тогда, когда сервис уходил в staging. К этому моменту релиз уже был близко к GA. Архитектурные вопросы поднимались поздно. Незначительное изменение конфигурации и критичный редизайн аутентификации проходили через одинаковый процесс. Это не масштабировалось [23].

Решение — risk-based triage по типу изменения и критичности сервиса: для high/critical сервисов мануальный ревью обязателен независимо от ответов на triage-вопросы. Автоматически закрытые релизы аудируются раз в месяц для валидации triage-решений.

Этот подход — не замена SAST/SCA, а дополнительный уровень: решение по конкретному изменению до merge/release.

Тренды и что будет дальше

Несколько тенденций уже определяют следующий период:

AI-ассистенты как источник risk. Vibe Security Radar Georgia Tech фиксирует рост CVE, введённых AI: 6 в январе, 15 в феврале, 35+ в марте 2026 [48]. Тренд не замедляется. Governance-фреймворки для AI-кодинга — PromptBOM, provenance tracking, раздельная политика для критичных модулей — только формируются.

NVD и кризис базы данных уязвимостей. NIST прекратил обогащение CVE в 2024 году [44]. Команды, полагающиеся только на NVD, имеют структурный пробел в SCA-покрытии. Переход на GitHub Advisory Database, OSV или vendor-специфичные источники — практическая необходимость.

Secrets sprawl в collaboration tools и CI/CD. 28% инцидентов с секретами — вне кода [4]. 59% скомпрометированных машин в атаках с кражей credentials — CI/CD runners, не ноутбуки [4]. Периметр контроля расширяется за пределы репозитория.

SBOM как обязательная практика. OWASP Top 10 2025 включил Software Supply Chain Failures как A03 [42]. CISA, NIS2, DORA давят в сторону обязательной трассируемости компонентов. SBOM из каждого доверенного билда — не optional для regulated-сектора.

Консолидация инструментов. 43% enterprise планировали сократить число security-инструментов в 2025 году [30]. Движение к платформам ASPM (Application Security Posture Management), корреляции findings и change-based приоритизации — логичный ответ на проблему tool sprawl и alert fatigue.

HighVibe: change-based review как готовый слой контроля

Описанный выше подход — анализ конкретного изменения, а не репозитория целиком — это не теоретическая конструкция. Именно так работает HighVibe.

HighVibe встраивается в процесс как дополнительный слой контроля рядом с SAST, SCA и secret scanning — не вместо них. Продукт анализирует конкретный diff: что изменилось в коде, конфигурации и служебных файлах, какие зависимости появились или обновились в этом PR (включая транзитивные), что несёт в себе этот релиз в контексте критичности сервиса.

Результат — не ещё один длинный security-отчёт, а короткий и понятный сигнал: можно принять, стоит перепроверить вот это, или — стоп, это блокирует выход. Без тотального сканирования всего репозитория, без лишней бюрократии, без подмены SAST/SCA.

Это особенно актуально для команд, которые уже используют AI-ассистенты: именно там разрыв между скоростью генерации кода и качеством его контроля наиболее выражен. Рабочий PR — это ещё не безопасный PR. HighVibe помогает ответить на вопрос, который другие инструменты не задают.

Подробнее — на highvibe.dev.

Что делать дальше

SAST, SCA и secret scanning — не конкурирующие инструменты. Это ортогональные слои: каждый закрывает свой класс рисков, которые другие не видят. Команде нужны все три.

Но есть вопрос, на который ни один из них не отвечает: «можно ли безопасно принять именно это изменение прямо сейчас?» Это вопрос change-based review — четвёртого уровня контроля, который работает с конкретным diff и контекстом релиза.

В мире AI-кодинга, где скорость генерации кода обогнала скорость его верификации, этот уровень становится не дополнительным, а структурно необходимым. PR, который прошёл все сканеры, не обязательно безопасен для merge. Разница между «технически прошёл проверки» и «можно безопасно принять» — это и есть пространство, которое закрывает change-based review.

Практический следующий шаг: пройти по последним десяти PR вашей команды и проверить — какие из них добавили новые зависимости в lock-файл, что изменилось в конфигурации и служебных файлах, и было ли принято явное решение «это безопасно принять прямо сейчас» — или это просто «тесты прошли, merge».

Источники

[1] 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/

[2] GitHub Blog — "SCA vs SAST: what are they and which one is right for you?" — https://github.blog/security/supply-chain-security/sca-vs-sast-what-are-they-and-which-one-is-right-for-you/

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

[4] GitGuardian — "The State of Secrets Sprawl 2026: 9 Takeaways for CISOs" — https://thehackernews.com/2026/03/the-state-of-secrets-sprawl-2026-9.html

[5] GitGuardian — "AI Is Fueling Secrets Sprawl" — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026-pr/

[6] SoftwareSeni — "AI-Generated Code Security 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/

[7] Kusari — "Vibe Coding Is Shipping Vulnerabilities: A Security Team's Guide" — https://www.kusari.dev/blog/vibe-coding-is-shipping-vulnerabilities-a-security-teams-guide-to-ai-generated-code-risks

[8] MITRE CWE — Common Weakness Enumeration — https://cwe.mitre.org/

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

[10] Endor Labs — "False Negatives in SAST: Hidden Risks Behind the Noise" — https://www.endorlabs.com/learn/false-negatives-in-sast-hidden-risks-behind-the-noise

[11] Contrast Security — "AppSec noise and fatigue by the numbers" — https://www.contrastsecurity.com/infographics/appsec-noise-and-fatigue-by-the-numbers

[12] Astra — "What's a False Positive & How to Triage It in SAST+DAST?" — https://www.getastra.com/blog/dast/false-positive-triage/

[13] AppSec Santa — "Supply Chain Attacks: Types, Examples & Defense (2026)" — https://appsecsanta.com/sca-tools/supply-chain-attacks-guide

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

[15] Qualys — "When Dependencies Turn Dangerous: Responding to the NPM Supply Chain Attack" — https://blog.qualys.com/vulnerabilities-threat-research/2025/09/10/when-dependencies-turn-dangerous-responding-to-the-npm-supply-chain-attack

[16] GitGuardian — "70% of Leaked Secrets Stay Active Two Years Later" — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2025-pr/

[17] ProjectDiscovery — "New Report: State of AppSec 2026" — https://projectdiscovery.io/blog/new-report-state-of-appsec-2026-security-at-engineering-speed

[18] OWASP Top 10 2025 — "A03 Software Supply Chain Failures" — https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/

[19] Pixee — "91% of SAST findings are false positives" — https://www.pixee.ai/blog/sast-false-positives-reduction

[20] Postman Blog — "How We Scaled Security Reviews Without Slowing Down Engineering" — https://blog.postman.com/how-we-scaled-security-reviews-without-slowing-down-engineering/

[21] Infosecurity Magazine — "How Security Leaders Can Safeguard Against Vibe Coding Security Risks" — https://www.infosecurity-magazine.com/news-features/how-safeguard-vibe-coding-security/

[22] Cloud Security Alliance — "Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt" — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-security-vibe-coding-202/

[23] Postman Blog — "How We Scaled Security Reviews Without Slowing Down Engineering" — https://blog.postman.com/how-we-scaled-security-reviews-without-slowing-down-engineering/

[24] OpenText Blogs — "5 urgent signals your AppSec program can't ignore in 2025" — https://blogs.opentext.com/5-urgent-signals-your-appsec-program-cant-ignore-in-2025/

[25] ISACA Now Blog — "The 2025 Software Supply Chain Security Report" — https://www.isaca.org/resources/news-and-trends/isaca-now-blog/2025/the-2025-software-supply-chain-security-report