SAST против DAST: когда какой инструмент выбрать
SAST и DAST — это не конкуренты, а два разных взгляда на безопасность приложения. **SAST** (статический анализ) читает исходный код изнутри и находит уязвимые места ещё до запуска. **DAST** (динамический анализ) атакует уже работающее приложение снаружи, как это сделал бы злоумышленник. Рядом стоят **IAST** (анализ изнутри запущенного приложения) и **SCA** (контроль сторонних и open source библиотек). **Если коротко:** выбор «или SAST, или DAST» — ложная дилемма. Зрелый процесс безопасной разработки (DevSecOps) использует их вместе на разных этапах SDLC: SAST и SCA — раньше, на коде и сборке; DAST и IAST — позже, на тестовом стенде. Ниже разбираем, что именно анализирует каждый инструмент, на каком этапе включается, в чём сильные и слабые стороны (включая ложные срабатывания) и как собрать связку под вашу зрелость. Сравнить конкретных поставщиков по подтверждённым сигналам можно в [рейтинге SAST, DAST и SCA](/rating/appsec-testing-sast-dast-sca).
AppSec-проверки должны быть встроены в разработку
SAST, DAST и SCA полезны, когда результаты связаны с пайплайном, владельцами кода и приоритизацией исправлений.
Рейтинги подрядчиков по теме исследования
Если после чтения нужен короткий список исполнителей, начните с профильных рейтингов cyber-index.ru: в них видны компании, кейсы, интервью, категории экспертизы и доверительный индекс.
Как проверять выводы исследования
Используйте материал как основу для shortlist: сопоставьте выводы с профилями компаний, связанными рейтингами, кейсами, интервью клиентов и источниками. Если в статье есть список источников, начинайте проверку с него; если источников мало, дополнительно запросите у подрядчика методику, baseline и примеры работ.
Что анализирует каждый инструмент
Главное различие — в том, что именно «видит» инструмент и нужен ли ему запущенный код.
- **SAST (Static Application Security Testing)** — анализирует исходный код, байт-код или бинарник, не запуская приложение. Видит логику изнутри, понимает поток данных (data flow) и находит классы уязвимостей вроде SQL-инъекций, XSS, небезопасной работы с памятью, захардкоженных секретов. Не требует развёрнутого стенда. - **DAST (Dynamic Application Security Testing)** — тестирует уже запущенное приложение «снаружи», без доступа к коду (black box). Шлёт реальные запросы и наблюдает реакцию: находит то, что проявляется только в рантайме — ошибки конфигурации, проблемы аутентификации, уязвимости на стыке компонентов. - **IAST (Interactive Application Security Testing)** — работает изнутри запущенного приложения через агент/инструментацию. Совмещает плюсы обоих подходов: видит и код, и поведение в рантайме, что даёт меньше ложных срабатываний. Цена — необходимость встроить агент и прогнать функциональные тесты. - **SCA (Software Composition Analysis)** — анализирует не ваш код, а сторонние и open source зависимости: ищет известные уязвимости (CVE), проблемные лицензии и устаревшие версии. Критичен, потому что значительная часть кодовой базы современных приложений — это чужие библиотеки.
На каком этапе SDLC включается каждый
Ценность инструмента сильно зависит от того, когда он срабатывает. Чем раньше найдена уязвимость, тем дешевле её исправить (принцип «сдвига влево», shift left).
- **Код / коммит.** SAST и поиск секретов встраиваются в IDE и pre-commit хуки — разработчик видит проблему сразу, до пуша. - **Сборка / CI.** SAST на полном объёме, SCA по манифестам зависимостей — гейт в пайплайне, который блокирует сборку при критичных находках. - **Тестирование / стенд.** DAST и IAST требуют развёрнутого приложения, поэтому работают на тестовом или staging-окружении, часто вместе с функциональными автотестами. - **Прод / эксплуатация.** Периодический DAST-скан, повторный SCA при появлении новых CVE в уже используемых библиотеках, мониторинг.
Где каждый тип анализа даёт максимум
Плюсы, минусы и ложные срабатывания
У каждого подхода своя «слепая зона». SAST видит код, но не видит рантайм-окружение, поэтому склонен к ложным срабатываниям (false positive) — отмечает теоретически опасный код, который на практике недостижим. DAST, наоборот, почти не даёт ложных срабатываний (если он что-то воспроизвёл — это реально работает), но пропускает уязвимости в коде, который не попал под тестовые сценарии (false negative), и не показывает точное место в коде. IAST балансирует точность, но требует инструментации и хорошего покрытия тестами. SCA точен по известным CVE, но бессилен против уязвимостей в вашем собственном коде.
Сравнение SAST, DAST, IAST и SCA
| Критерий | SAST | DAST | IAST | SCA |
|---|---|---|---|---|
| Что анализирует | Исходный код / байт-код | Работающее приложение снаружи | Приложение изнутри в рантайме | Сторонние и open source зависимости |
| Нужен запуск приложения | Нет | Да | Да | Нет |
| Доступ к коду | Да (white box) | Нет (black box) | Да (gray box) | Манифесты зависимостей |
| Этап SDLC | Код, сборка/CI | Тест, прод | Тест/QA | Сборка/CI |
| Ложные срабатывания | Высокие | Низкие | Низкие | Низкие |
| Указывает место в коде | Да, точно | Нет | Да | Да (до версии библиотеки) |
| Типичные находки | Инъекции, XSS, секреты | Конфиг, аутентификация, рантайм | Совмещённо | Известные CVE, лицензии |
Что есть на российском рынке
Для ориентира: на отечественном рынке анализа защищённости приложений присутствуют PT Application Inspector (Positive Technologies), Solar appScreener (Ростелеком-Солар) и Стингрей (Stingray). Это не рейтинг и не рекомендация — места, баллы и подтверждённые сигналы смотрите в [рейтинге категории](/rating/appsec-testing-sast-dast-sca). Одни решения исторически сильнее в SAST, другие движутся к покрытию нескольких типов анализа в одной платформе; актуальный охват и сертификацию проверяйте в первоисточниках под вашу задачу.
Зрелость класса инструментов AppSec-тестирования
Усреднённая редакционная оценка готовности класса по открытым данным. Это не вендорский бенчмарк и не заменяет пилот на вашем коде и стеке.
Чек-лист: какой инструмент когда
Как внедрять анализ защищённости: 5 шагов
-
01
Инвентаризация
Зафиксируйте языки, фреймворки, состав зависимостей и текущий CI/CD-пайплайн — это вход для подбора инструментов.
-
02
Старт с SAST и SCA
Подключите статический анализ и контроль зависимостей в режиме мониторинга, без блокирующих гейтов.
-
03
Настройка и триаж
Уберите шум: подавите заведомые ложные срабатывания, задайте политику критичности находок.
-
04
DAST и/или IAST на стенде
Добавьте динамический анализ на тестовом окружении вместе с функциональными автотестами.
-
05
Гейты и регулярность
Переведите проверки в блокирующие гейты по критичным находкам и поставьте повторные сканы на расписание.
Как мы оцениваем поставщиков
cyber-index.ru не продаёт места в рейтинге. Поставщики SAST, DAST, IAST и SCA сравниваются по проверяемым сигналам: подтверждённые внедрения и кейсы, отзывы и интервью клиентов, внешняя репутация, специализация, прозрачность и свежесть данных. Поэтому статью стоит читать в связке с [рейтингом категории](/rating/appsec-testing-sast-dast-sca): здесь — типы анализа и критерии выбора, там — сравнение конкретных компаний по подтверждённым фактам.
Следующий шаг
Разобрались с типами анализа — переходите к сравнению поставщиков: **[рейтинг SAST, DAST и SCA →](/rating/appsec-testing-sast-dast-sca)**. Полезно прочитать рядом: [рейтинг российских SAST/DAST-решений 2026](/research/rejting-rossijskih-sast-dast-2026), [чем заменить Checkmarx, Fortify и Veracode](/research/zamena-checkmarx-fortify-veracode) и [SCA и контроль open source](/research/sca-kontrol-open-source-zavisimostej).
Частые вопросы
Что лучше — SAST или DAST?
Это неправильная постановка вопроса: они решают разные задачи. SAST находит уязвимости в коде на раннем этапе, DAST — проблемы работающего приложения снаружи. В зрелом процессе их используют вместе, а не выбирают одно вместо другого.
Можно ли обойтись только одним инструментом?
На старте — да, обычно начинают с SAST или с SCA, если много open source. Но один класс оставляет слепые зоны: SAST не видит рантайм, DAST не указывает место в коде, SCA не проверяет ваш собственный код. Для полного покрытия нужна связка.
Почему SAST даёт так много ложных срабатываний?
Потому что он анализирует код, не запуская его, и не знает реального окружения — поэтому помечает потенциально опасные конструкции, которые на практике могут быть недостижимы. Снижается это триажем, настройкой правил и базовой линией (baseline) до включения гейтов.
Чем IAST отличается от SAST и DAST?
IAST работает изнутри запущенного приложения через агент: он видит и код, и поведение в рантайме одновременно. За счёт этого даёт меньше ложных срабатываний, но требует инструментации и хорошего покрытия функциональными тестами.
Где сравнить конкретных вендоров между собой?
В рейтинге SAST, DAST и SCA — там поставщики ранжированы по подтверждённым сигналам, а не по рекламе.
Источники и метод проверки
SAST и DAST — это не конкуренты, а два разных взгляда на безопасность приложения. **SAST** (статический анализ) читает исходный код изнутри и находит уязвимые места ещё до запуска. **DAST** (динамический анализ) атакует уже работающее приложение снаружи, как это сделал бы злоумышленник. Рядом стоят **IAST** (анализ изнутри запущенного приложения) и **SCA** (контроль сторонних и open source библиотек). **Если коротко:** выбор «или SAST, или DAST» — ложная дилемма. Зрелый процесс безопасной разработки (DevSecOps) использует их вместе на разных этапах SDLC: SAST и SCA — раньше, на коде и сборке; DAST и IAST — позже, на тестовом стенде. Ниже разбираем, что именно анализирует каждый инструмент, на каком этапе включается, в чём сильные и слабые стороны (включая ложные срабатывания) и как собрать связку под вашу зрелость. Сравнить конкретных поставщиков по подтверждённым сигналам можно в [рейтинге SAST, DAST и SCA](/rating/appsec-testing-sast-dast-sca).