SAST, DAST, SCA: инструменты безопасности в CI/CD

Почему безопасность нельзя добавить «потом»

Долгое время безопасность жила по другую сторону стены от разработки. Команда писала код, тестировала функциональность, релизила — и где-то ближе к продакшену передавала продукт «безопасникам на проверку». Те находили проблемы. Разработчики возвращались к уже закрытым задачам. Цикл повторялся. По данным IBM, стоимость устранения уязвимости, найденной в продакшене, в среднем в 15 раз выше, чем той же уязвимости, обнаруженной на этапе разработки.

DevSecOps меняет этот порядок радикально: безопасность встраивается в каждый шаг CI/CD-пайплайна, а не ждёт у финишной черты. Три ключевых инструментальных подхода этой модели — SAST, DAST и SCA — перекрывают разные векторы рисков: уязвимости в собственном коде, небезопасные зависимости и бреши в работающем приложении. Понять, что делает каждый из них и где его правильно разместить в пайплайне, — задача этой статьи.

Что такое SAST, DAST и SCA — и чем они отличаются

Все три подхода решают одну задачу — находить уязвимости. Но каждый смотрит на приложение под своим углом: один анализирует текст кода, другой — состав библиотек, третий — поведение запущенной системы. Путаница между ними — один из главных источников ошибок при построении AppSec-программы.

SAST: анализ кода без его запуска

SAST — Static Application Security Testing. Инструмент получает исходный код или скомпилированный байткод и анализирует его статически: без запуска, без сети, без базы данных. По сути это очень умный поиск паттернов: SQL-инъекции, небезопасная работа с памятью, жёстко прописанные секреты, небезопасная десериализация — всё это можно обнаружить, читая код.

Главное преимущество SAST — ранний запуск. Инструмент можно встроить прямо в IDE (как плагин) или запускать при каждом коммите, ещё до слияния кода в основную ветку. Главное ограничение — высокий уровень ложных срабатываний: SAST не знает контекста исполнения и нередко помечает безопасный код как проблемный. Это требует настройки правил и регулярного тюнинга.

SCA: безопасность зависимостей

SCA — Software Composition Analysis. Современное приложение на 70–90% состоит из open-source компонентов: библиотек, фреймворков, транзитивных зависимостей. Каждая из них — потенциальная точка риска. SCA строит полное дерево зависимостей (Software Bill of Materials, SBOM) и проверяет каждый компонент по базам известных уязвимостей: NVD, GitHub Advisory Database, OSV.

Помимо CVE, SCA отслеживает лицензионные риски — критично для коммерческих продуктов, где неправильная лицензия компонента может привести к юридическим проблемам. После инцидентов с Log4Shell и XZ Utils SCA из «желательного» инструмента превратился в обязательный: транзитивные уязвимости в глубоко вложенных зависимостях невозможно отследить вручную.

DAST: тестирование работающего приложения

DAST — Dynamic Application Security Testing. В отличие от SAST и SCA, DAST не нуждается в доступе к коду. Он работает снаружи: запускает приложение и атакует его через интерфейс — отправляет специально сформированные HTTP-запросы, перебирает параметры, проверяет заголовки ответов. Это ближе всего к тому, что делает атакующий в реальной жизни.

DAST хорошо ловит то, что SAST пропускает в силу отсутствия контекста: XSS, SSRF, проблемы аутентификации и авторизации, некорректные конфигурации сервера. Ограничение — медленная работа (полный скан может занимать часы) и необходимость задеплоенного окружения. Поэтому DAST обычно запускают не при каждом коммите, а на этапе staging или ночью по расписанию.

Сравнение SAST, DAST и SCA

Три метода не конкурируют — они дополняют друг друга. Использование только одного из них оставляет значительные слепые зоны. Ниже — сводная таблица ключевых характеристик:

Где встроить каждый инструмент в CI/CD

Знать, что делает инструмент, — половина дела. Вторая половина — правильно разместить его в пайплайне: запустить слишком рано без достаточного контекста бесполезно, запустить слишком поздно — дорого. Каждый из трёх методов имеет своё естественное место в жизненном цикле сборки.

Этап commit и pull request

На этом этапе время — главная ценность: разработчик ещё в контексте задачи и может исправить проблему немедленно. Здесь уместны два инструмента. SAST в режиме diff — анализирует только изменённые строки кода, а не весь репозиторий. Это делает сканирование быстрым (секунды) и релевантным: разработчик видит замечание прямо в PR-комментарии. SCA при любом изменении зависимостей — срабатывает при добавлении или обновлении библиотеки в package.json, requirements.txt, pom.xml. Блокировать merge при наличии критичной CVE — стандартная и оправданная практика.

Этап build и staging

На этапе сборки SAST запускается уже в полном объёме — по всей кодовой базе, с полным набором правил. Результаты идут в дашборд, а не только в PR-комментарии: здесь важна агрегированная картина технического долга по безопасности. Параллельно — сканирование контейнерного образа: Trivy или Grype проверяют финальный Docker-образ на CVE в системных пакетах и библиотеках. Это отдельный слой, который не покрывает ни SAST, ни SCA приложения.

На staging деплоится рабочая версия приложения — именно здесь включается DAST. Автоматический сканер (OWASP ZAP, Nuclei) запускает базовую проверку: пассивное сканирование при каждом деплое, активное сканирование по расписанию (ночью или перед релизом). Результаты DAST часто дополняются ручным пентестом перед крупными релизами.

Quality Gate: когда останавливать сборку

Quality Gate — порог, при превышении которого пайплайн падает и деплой не происходит. Это самый болезненный вопрос при внедрении: слишком жёсткий порог парализует команду, слишком мягкий — не даёт никакого эффекта. Практический подход: на старте внедрения ставить gate только на Critical/High без исключений; Medium — в режиме warning без блокировки; первые 2–3 месяца — режим обучения и настройки правил, а не блокировок.

Популярные инструменты: открытые и коммерческие

Выбор инструмента зависит от языка, архитектуры и зрелости команды. Ниже — актуальная карта решений по каждой категории: от бесплатных open-source вариантов до enterprise-платформ.

SAST-инструменты

Semgrep — один из наиболее популярных открытых SAST-инструментов: быстрый, с гибкими кастомными правилами на YAML, поддерживает 30+ языков. Отлично встраивается в GitHub Actions и GitLab CI. CodeQL (GitHub) — мощный семантический анализатор, работающий на базе запросов к графу кода; бесплатен для публичных репозиториев, входит в GitHub Advanced Security для корпоративных пользователей. Checkmarx SAST и Veracode — enterprise-решения с расширенной отчётностью, интеграцией с JIRA/ServiceNow и управлением ложными срабатываниями на уровне политик. Из российских инструментов активно развивается PT Application Inspector от Positive Technologies.

SCA-инструменты

OWASP Dependency-Check — классический бесплатный инструмент, поддерживает Java, .NET, Node.js, Python; интегрируется в Maven, Gradle, Jenkins. Trivy от Aqua Security — универсальный сканер: покрывает файловую систему, контейнерные образы, Git-репозитории и SBOM; де-факто стандарт для контейнерных сред. Snyk — коммерческая платформа с удобным developer experience: находит уязвимости, предлагает патч-рекомендации и PR с исправлением прямо в GitHub. GitHub Dependabot — встроенный в GitHub механизм: автоматически создаёт PR на обновление уязвимых зависимостей.

DAST-инструменты

OWASP ZAP (Zed Attack Proxy) — наиболее распространённый open-source DAST-инструмент с режимом автоматизированного сканирования и поддержкой CI-интеграции через Docker-образ. Nuclei от ProjectDiscovery — шаблонизированный сканер с огромной библиотекой community-шаблонов: особенно эффективен для проверки конфигурационных уязвимостей и CVE-специфичных проверок. Burp Suite Pro — стандарт де-факто для ручного тестирования; Enterprise-версия позволяет встроить сканирование в CI/CD. StackHawk — современный DAST с API-first подходом, нативной интеграцией в GitHub Actions и GitLab CI.

IAST и RASP: ещё два подхода

SAST, SCA и DAST — базовая троица. Но существуют ещё два подхода, которые упоминаются реже, хотя занимают важную нишу в зрелых AppSec-программах.

IAST (Interactive Application Security Testing) работает изнутри: агент внедряется в JVM или среду выполнения и мониторит поведение приложения в реальном времени во время функционального тестирования. IAST видит точный поток данных от входного параметра до уязвимой операции — это обеспечивает крайне низкий уровень ложных срабатываний. Платой за точность становится необходимость поддерживаемого рантайма и ограниченное покрытие языков. RASP (Runtime Application Self-Protection) — это уже не тестирование, а защита в продакшене: агент, встроенный в приложение, перехватывает потенциально опасные вызовы в реальном времени и блокирует их до выполнения. Это последний рубеж, когда другие меры не сработали.