SAST и DAST: как выбрать подходящий метод тестирования безопасности

от

«Если у вас нет проблемы — решения не нужны. Но когда вы пытаетесь запустить код, который уже написан, вопрос ‘как его проверить?’ становится главным. SAST и DAST — два разных ответа, которые часто путают или используют неправильно. Разберёмся, зачем они нужны и как выбрать.»

Откуда взялись SAST и DAST и что они на самом деле делают

SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing) появились как реакция на две разные стадии разработки. SAST отвечает на вопрос «что не так в коде, который я пишу?», а DAST — «что не так с программой, которую я запустил?». Разница не просто в «статике» и «динамике», а в точке, где вы применяете проверку.

SAST работает с исходным кодом, бинарными файлами или даже промежуточными представлениями (например, байт-кодом Java) до запуска программы. Он не требует запущенного приложения. DAST требует работающую систему — веб-сервер, API, микросервис. Он взаимодействует с ней как внешний пользователь или злоумышленник.

Сравнение часто сводится к таблице, но смысл лучше понять через задачу:

Что проверяет Когда работает Что видит
SAST Код, структуры, зависимости, конфигурации в исходниках На этапе написания, компиляции, сборки
DAST Запущенное приложение через сеть, интерфейсы, протоколы После деплоя, в тестовом или даже production-окружении

Ошибка в выборе часто происходит из-за того, что команда пытается использовать SAST для поиска проблем конфигурации сервера (который ещё не запущен) или DAST для поиска уязвимости в библиотеке, которая не подключена в финальный бинарный файл.

SAST: как это работает внутри и почему он не видит всё

SAST-инструмент не «читает» код как человек. Он строит модель программы: граф вызовов функций, дерево зависимостей, поток данных. На этой модели он применяет правила (политики), которые описывают потенциально опасные паттерны.

Пример простого правила для SAST: «Если функция получает данные от пользователя и передаёт их в SQL-запрос без проверки, это потенциальная SQL-инъекция». Инструмент найдёт в коде путь от точки ввода (например, параметра HTTP-запроса) до точки выполнения SQL. Но он не знает, запустится этот путь в реальности или нет, потому что не учитывает логику условий.

Типичные находки SAST:

  • Потенциальные инъекции (SQL, командная, кодовая)
  • Небезопасное использование крипто-функций (например, постоянный seed для генератора случайных чисел)
  • Уязвимости в зависимостях (по анализу импортов и версий)
  • Проблемы с управлением памятью (для языков типа C/C++)
  • Небезопасная обработка файлов или сетевых данных

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

[КОД: пример правила SAST для поиска SQL-инъекции в Java]


// SAST-правило (псевдокод логики инструмента)
Find: MethodCall(sqlQueryExecution)
Where: ItsArgument comesFrom Source(userInput)
And: NoIntermediateCall(sanitizeFunction)
Flag: PotentialSQLInjection

Когда SAST бесполезен или даёт ложные результаты

SAST даёт много ложноположительных результатов (false positives), когда код сложный или использует шаблоны, которые инструмент не понимает. Например, кастомная функция валидации, которую SAST не знает, может быть пропущена, и он будет считать данные не проверенными.

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

Инструменты SAST различаются по поддерживаемым языкам и глубине анализа. Некоторые работают только на поверхности кода (pattern-based), другие строят полноценные модели (flow-based). Выбор зависит от того, насколько глубоко вам нужно анализировать и сколько ложных срабатываний вы готовы терпеть.

DAST: что происходит во время «атаки» и почему он не заглядывает внутрь

DAST-инструмент имитирует действия злоумышленника против работающего приложения. Он не знает исходного кода, внутренней структуры или бизнес-логики. Он работает через интерфейсы: HTTP-запросы, API-эндпоинты, формы, cookies, заголовки.

DAST отправляет запросы с модифицированными параметрами, пытаясь вызвать ошибки, получить неожиданные ответы или обнаружить уязвимые точки. Например, он может добавить в параметр SQL-метасимволы и проверить, вернёт сервер ошибку базы данных или обработает запрос нормально.

Типичные находки DAST:

  • Работающие SQL-, командные, код-инъекции
  • Проблемы аутентификации и сессий (например, возможность перехвата сессии)
  • Уязвимости конфигурации сервера (неправильные заголовки, доступ к внутренним файлам)
  • CSRF (Cross-Site Request Forgery), если есть соответствующие интерфейсы
  • Ошибки в обработке файлов (загрузка, чтение)

DAST видит только то, что доступно через интерфейсы. Если уязвимость находится в части кода, которая не экспортируется наружу (например, внутренняя функция обработки данных), DAST её не обнаружит. Также DAST может пропустить сложные многозапросные атаки, если инструмент не настроен на такие сценарии.

[КОД: пример запроса DAST для проверки SQL-инъекции]


GET /api/user?id=1' OR '1'='1
Host: example.com
Cookie: session=abc123
...
// DAST анализирует ответ: если в теле есть сообщения типа "SQL syntax error", 
// или время ответа значительно увеличилось — возможно, инъекция работает.

Ограничения DAST: скорость, покрытие и влияние на систему

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

DAST часто не покрывает все эндпоинты автоматически, особенно если приложение использует сложную логику доступов или динамические пути. Инструмент нужно настраивать — указывать точки входа, параметры аутентификации, исключать опасные тесты для production.

DAST также зависит от окружения. Проверка на тестовом стенде может дать другие результаты, чем на production, из-за различий в конфигурациях, версиях компонентов или сетевых правилах.

Как выбрать: SAST, DAST или вместе?

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

SAST лучше применять:

  • В процессе разработки, особенно при коммитах или в CI (Continuous Integration)
  • Для проверки новых библиотек и зависимостей перед интеграцией
  • Когда нужно быстро оценить большой объём кода без запуска среды
  • Для поиска проблем, которые трудно воспроизвести в runtime (например, уязвимости в крипто-алгоритмах)

DAST лучше применять:

  • После деплоя на тестовое окружение, перед выпуском в production
  • Для проверки готового продукта, включая конфигурации серверов и сетевые правила
  • Когда нужно оценить безопасность взаимодействия нескольких сервисов
  • Для имитации реальных атак с учётом полного стека технологий

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

Интеграция в процесс разработки: не только инструменты

SAST и DAST — инструменты, но их эффективность зависит от процесса. SAST, интегрированный в CI/CD, может автоматически проверять каждый коммит и блокировать мержи при критических проблемах. DAST может запускаться автоматически после успешного деплоя на тестовый стенд и предоставлять отчет перед выпуском.

Ключевая проблема — управление ложноположительными результатами. Если SAST выдаёт сотни предупреждений, из которых реальных уязвимости 5–10%, разработчики начинают игнорировать его. Нужно настроить правила, исключить известные ложные паттерны и сосредоточиться на критических рисках.

Для DAST важно правильно настроить окружение тестирования: оно должно быть максимально близко к production, но без риска повредить данные или вызвать отказ обслуживания. Часто используют специальные тестовые стенды, которые периодически обновляются из последних версий.

Что не заменят SAST и DAST: ручное тестирование и аудит

SAST и DAST автоматизируют поиск известных паттернов уязвимости. Но они не заменяют ручное тестирование (penetration testing) и глубинный аудит безопасности. Автоматические инструменты не понимают бизнес-логику, не могут оценить сложные сценарии атак, которые требуют креативного подхода.

Ручное тестирование дополняет автоматическое, особенно для:

  • Проверки сложных механизмов аутентификации и авторизации
  • Анализа логики приложения, которая может привести к нестандартным уязвимостям
  • Оценки безопасности интеграций с внешними системами, которые не покрываются стандартными тестами
  • Поиска проблем, возникающих из-за комбинации нескольких небольших недочётов

Автоматизация (SAST/DAST) и ручное тестирование вместе образуют полноценный цикл проверки безопасности.

Российский контекст: требования и практика

В российской регуляторике (например, требования ФСТЭК, 152-ФЗ) часто упоминается необходимость проверки безопасности информационных систем. SAST и DAST могут использоваться как часть процессов обеспечения безопасности разработки (Secure Development Lifecycle).

При выборе инструментов важно учитывать поддержку русскоязычной документации, интеграцию с популярными в России CI/CD системами (например, Jenkins, GitLab CI), а также возможность работать с кодом на языках, распространённых в локальных проектах.

Также стоит учитывать, что некоторые зарубежные инструменты могут иметь ограничения или требуют адаптации под локальные стандарты и практики. Внимание стоит уделять инструментам, которые можно развернуть внутри инфраструктуры организации, без зависимости от внешних облачных сервисов.

Итог: не «или», а «и», но в правильном порядке

SAST и DAST решают разные задачи на разных этапах жизненного цикла приложения. SAST, это профилактика, поиск проблем в коде до того, как они станут частью работающей системы. DAST, это проверка иммунитета, убеждение, что запущенная система устойчива к атакам.

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

Автоматизация не устраняет необходимости думать о безопасности на всех этапах, но она делает процесс более системным и менее зависимым от случайных факторов.

Оставьте комментарий