SAST, DAST, SCA и MAST: в чём разница и что выбрать

SAST проверяет исходный код без запуска, DAST атакует работающее приложение снаружи, SCA ищет уязвимости в open-source зависимостях, а MAST тестирует мобильные приложения. Это не конкуренты, а слои одной защиты: начинать лучше с SCA и SAST, затем добавлять DAST, а MAST и бинарный анализ подключать по необходимости.

SAST — статический анализ кода

Static Application Security Testing анализирует исходный (или бинарный) код без запуска приложения. В руководстве OWASP DevSecOps Guideline SAST описан как разновидность статического анализа кода, часть code review по принципу «белого ящика». Сканер строит модель программы, отслеживает потоки данных от входных точек до опасных функций и находит SQL-инъекции, XSS, path traversal, небезопасную криптографию, захардкоженные пароли и ключи.

Плюсы: работает на самых ранних этапах — в IDE или при pull request; указывает точную строку кода, поэтому разработчику проще исправить дефект.
Минусы: не видит проблем конфигурации окружения; без настройки правил может давать ложные срабатывания; качество сильно зависит от поддержки конкретного языка и фреймворка.

О том, как оценивать SAST-анализаторы перед покупкой, мы писали в материале как выбрать SAST-анализатор.

DAST — динамическое тестирование

Dynamic Application Security Testing — это «чёрный ящик»: инструмент атакует работающее приложение снаружи, как это сделал бы злоумышленник, отправляет запросы, подставляет вредоносные данные и анализирует ответы. По описанию OWASP, DAST особенно полезен для проверки входных и выходных данных, аутентификации и ошибок конфигурации сервера, при этом исходный код и знание фреймворка не требуются.

Плюсы: находит реально эксплуатируемые уязвимости, проблемы конфигурации, аутентификации и сессий; не зависит от языка разработки; после настройки требует минимум участия — например, ночные запуски по расписанию.
Минусы: нужен развёрнутый стенд; срабатывает позже, чем SAST; не указывает на строку кода, из-за которой возникла уязвимость.

Для регулярного автоматического сканирования десятков и сотен сайтов используют платформы вроде Burp Suite DAST, для ручного тестирования пентестерами — Burp Suite Professional.

SCA — анализ состава ПО

Software Composition Analysis проверяет сторонние open-source библиотеки, из которых состоит значительная часть кода современных приложений. SCA находит компоненты с известными уязвимостями (CVE), вредоносные пакеты, проблемные лицензии и формирует SBOM — перечень всех компонентов. Использование уязвимых и устаревших компонентов входит в OWASP Top 10 2021 отдельной категорией A06.

Log4Shell показал масштаб риска: уязвимость CVE-2021-44228 в библиотеке Apache Log4j позволяла неаутентифицированному злоумышленнику удалённо выполнить код через специально сформированный запрос. CISA в декабре 2021 года описывала активную и массовую эксплуатацию, а так как Log4j встроена в продукты самых разных вендоров, пострадавших было много. Решения класса SCA, например Sonatype Lifecycle и Repository Firewall, позволяют быстро узнать, где используется уязвимый компонент, и заблокировать вредоносный пакет до попадания в сборку. Подробнее о перечне компонентов — в статье о SBOM в нашем блоге.

MAST — безопасность мобильных приложений

Mobile Application Security Testing объединяет статический и динамический анализ для Android и iOS. Ориентиром служат проекты OWASP: стандарт верификации MASVS с группами требований (хранение данных, криптография, аутентификация, сетевое взаимодействие, взаимодействие с платформой, качество кода, устойчивость к реверс-инжинирингу, приватность) и руководство по тестированию MASTG. Типичные находки: небезопасное хранение данных на устройстве, слабая защита трафика, утечки через логи, избыточные разрешения.

Бинарный анализ

Позволяет проверить приложения, для которых нет исходного кода: legacy-системы, решения подрядчиков, сторонние сборки. Особенно актуален при приёмке ПО и поиске недекларированных возможностей (НДВ), когда доверять поставщику «на слово» нельзя.

Сравнение классов инструментов

SAST — что проверяет: собственный код; когда: при написании и pull request; нужен код: да.
SCA — что проверяет: open-source зависимости; когда: при сборке и постоянно; нужен код: манифесты или сборка.
DAST — что проверяет: работающее веб-приложение и API; когда: на тестовом стенде и в проде; нужен код: нет.
MAST — что проверяет: мобильные приложения; когда: перед публикацией; нужен код: желательно.
Binary — что проверяет: исполняемые файлы; когда: при приёмке ПО; нужен код: нет.

IAST (интерактивный анализ с агентом внутри приложения) встречается реже и обычно рассматривается как дополнение к перечисленным классам, а не как замена.

Что выбрать в первую очередь?

Ответ «что-то одно» почти всегда неверен: инструменты дополняют друг друга. Практичный порядок для большинства компаний:

SCA — быстрый эффект, мало ложных срабатываний, закрывает самый массовый риск.
SAST — встраивается в pull request и учит разработчиков писать безопасно.
DAST — регулярное сканирование внешнего периметра веб-приложений.
MAST и бинарный анализ — если есть мобильные приложения или ПО от подрядчиков.

Платформы полного цикла, такие как DerScanner, объединяют SAST, DAST, SCA, MAST и бинарный анализ в одном интерфейсе — это упрощает внедрение и отчётность. Чтобы не покупать «вслепую», проведите сравнительный тест на своих репозиториях: как это организовать за месяц, описано в статье пилот SAST и SCA за 30 дней.

Как встроить проверки в процесс

Каждой проверке — своё место в конвейере. SAST и поиск секретов запускают на pull request, SCA — на сборке, DAST — на тестовом стенде и регулярно в проде. Важно заранее договориться, какие находки блокируют релиз, а какие превращаются в задачи. Начинайте с информирования и ужесточайте правила постепенно, иначе команда утонет в тысячах находок и начнёт обходить проверки.

Критерии выбора конкретного продукта

Когда класс инструмента определён, начинается выбор продукта. Универсального «лучшего» сканера не существует: результат зависит от вашего стека и процессов. На что стоит смотреть при сравнении:

Поддержка языков и фреймворков. Заявленный в презентации список языков ничего не говорит о глубине анализа. Проверяйте на своём коде: находит ли сканер известные дефекты в ваших проектах и как обрабатывает ваши фреймворки.
Доля ложных срабатываний. Если разработчики тратят время на разбор «шума», они перестанут доверять инструменту. Оценивайте не количество находок, а долю подтверждённых.
Интеграции. Сканер должен работать в вашем CI/CD, трекере задач и IDE. Находка, которую нельзя передать разработчику в привычном инструменте, останется в отчёте.
Модель развёртывания. Для банков и госсектора часто важно, чтобы исходный код не покидал периметр организации. Поэтому многие компании региона рассматривают решения, которые устанавливаются на собственной инфраструктуре (on-premise).
Отчётность. Руководству безопасности нужны сводки по приложениям, трендам и срокам исправления, а не только список дефектов.

Типичные ошибки при выборе

Один инструмент «на всё». Ожидание, что SAST закроет и зависимости, и конфигурацию окружения, приводит к слепым зонам.
Включение всех правил сразу. Тысячи находок на старом коде парализуют команду. Начинайте с критичных классов уязвимостей и новых изменений в pull request, а накопленный долг разбирайте постепенно.
Покупка без теста на своих данных. Сравнивайте кандидатов на одних и тех же репозиториях, иначе вы сравниваете презентации, а не продукты.
Игнорирование процесса. Инструмент без назначенных владельцев исправления и согласованных quality gates превращается в генератор отчётов.
Забытый мобильный и сторонний код. Мобильные клиенты и ПО подрядчиков часто остаются вне проверок, хотя именно через них приходят инциденты.

Кто чем пользуется в команде

Разные классы инструментов обслуживают разные роли. Разработчик работает с SAST и SCA: результаты приходят в pull request и IDE. DevOps-инженер отвечает за запуск проверок и политики в конвейере. Специалист по тестированию на проникновение использует DAST и ручные инструменты вроде Burp Suite для глубокой проверки критичных приложений. Руководитель ИБ смотрит сводные отчёты и метрики по всем классам. Если эти роли не разделить заранее, проверки либо не запускаются, либо результаты не доходят до тех, кто может их исправить.

Частые вопросы

Можно ли обойтись только DAST?

Нет. DAST не видит уязвимости, до которых не дошёл сканер, и не показывает строку кода. Он хорош для внешнего периметра, но не заменяет SAST и SCA, которые работают раньше и покрывают код и зависимости.

Чем SAST отличается от SCA?

SAST ищет дефекты в коде, который написали вы сами. SCA проверяет чужой код — сторонние библиотеки: известные уязвимости, лицензии и вредоносные пакеты.

Нужен ли MAST, если есть DAST?

Если у вас есть мобильные приложения — да. DAST проверяет серверную часть, а MAST — сам клиент: хранение данных на устройстве, защиту трафика, разрешения.

С какого инструмента лучше начать?

Обычно с SCA: он быстро показывает результат и даёт мало ложных срабатываний. Следующим шагом добавляют SAST в pull request, затем DAST для внешних приложений.

Не уверены, с чего начать? Эксперты AST Cyber Lab бесплатно подготовят карту DevSecOps для вашей компании в Казахстане или Центральной Азии.

Получить консультацию

Источники

Решения по теме

DerScanner →Burp DAST →Sonatype →