SAST, DAST, IAST и RASP различаются не только набором инструментов. Главное различие — в какой момент и из какой позиции система наблюдает приложение.
| Подход | Что наблюдает | Когда | Нужен запуск приложения |
|---|---|---|---|
| SAST | исходный код, байткод или другое представление программы | до или независимо от runtime | нет |
| DAST | поведение работающего приложения снаружи | runtime | да |
| IAST | поведение приложения изнутри во время выполнения | runtime | да |
| RASP | выполнение приложения и потенциально опасные операции | runtime, непосредственно внутри приложения | да |
Эти подходы дополняют друг друга. Они дают разные сигналы, требуют разных условий и закрывают разные части жизненного цикла приложения.
SAST: программа как структура
Static Application Security Testing анализирует приложение без выполнения его бизнес-сценариев. Инструмент исследует исходный код, AST, байткод, control flow, data flow и другие доступные представления программы, чтобы обнаружить потенциально небезопасные конструкции.
Упрощённый пример пути данных:
HTTP parameter → service → SQL query
SAST может установить, что непроверенное значение из HTTP-запроса достигает SQL-запроса, и отметить этот путь как потенциальную SQL injection.
Ключевая позиция:
SAST смотрит на программу как на структуру.
Такой анализ можно встроить в IDE, проверку pull request или CI. Он способен находить проблемы рано и указывать на конкретные участки кода, но не видит фактическую конфигурацию работающей системы и может строить пути, которые в реальном выполнении недостижимы.
DAST: приложение снаружи
Dynamic Application Security Testing работает с уже запущенным приложением и исследует его снаружи через реальные интерфейсы: HTTP, API и другие доступные endpoints.
Упрощённая модель наблюдения:
request → приложение → response
Инструмент отправляет специально подобранные входные данные и проверяет, удалось ли вызвать небезопасное поведение: обойти проверку доступа, внедрить данные в интерпретируемый контекст, получить лишнюю информацию или спровоцировать ошибку.
Ключевая позиция:
DAST смотрит не на код, а на наблюдаемое поведение работающей системы.
DAST проверяет приложение вместе с его runtime-конфигурацией и доступными интерфейсами, но обычно не знает, в какой строке кода возникла проблема. Качество результата зависит от того, какие маршруты, роли и состояния приложения удалось исследовать.
IAST: приложение изнутри во время выполнения
Interactive Application Security Testing работает внутри запущенного приложения во время ручного или автоматизированного тестирования. Обычно агент или инструментальная вставка получает runtime-информацию о том, какие функции выполнялись, куда прошли данные и какие опасные операции были вызваны.
DAST может видеть только внешнюю цепочку:
request → response
IAST способен связать запрос с внутренним путём выполнения:
request → controller → service → repository → SQL
Ключевая позиция:
IAST соединяет runtime-наблюдение с внутренним устройством приложения.
За счёт контекста выполнения IAST обычно точнее показывает источник и опасную операцию. Однако он анализирует только тот код, который действительно исполнился во время тестов: непокрытый сценарий остаётся ненаблюдаемым.
RASP: защита во время выполнения
Runtime Application Self-Protection располагается внутри runtime приложения и наблюдает потенциально опасные операции непосредственно во время выполнения. В отличие от подходов, ориентированных прежде всего на поиск уязвимостей, RASP может отреагировать на атаку: заблокировать операцию, прервать запрос или зарегистрировать событие для дальнейшего расследования.
Упрощённая схема:
входные данные → опасная операция → RASP блокирует выполнение
Ключевая позиция:
RASP не только наблюдает приложение, но и вмешивается в его выполнение.
RASP не устраняет дефект в коде. Он добавляет runtime-контроль, который может снизить вероятность эксплуатации уязвимости, но требует аккуратной настройки: ошибочная блокировка способна повлиять на легитимные запросы, а интеграция — на производительность и эксплуатацию приложения.
Главное различение
SAST:
наблюдаем программу без её выполнения.
DAST:
наблюдаем работающую программу снаружи.
IAST:
наблюдаем работающую программу изнутри.
RASP:
наблюдаем работающую программу изнутри
и можем вмешиваться в выполнение.
Из этого получаются три полезные оси:
| Ось | Вопрос |
|---|---|
| Статика / runtime | Нужно ли выполнить приложение, чтобы получить сигнал? |
| Снаружи / изнутри | Видит ли инструмент внутренний путь выполнения? |
| Обнаружение / защита | Только ли инструмент сообщает о проблеме или способен остановить опасную операцию? |
Почему одного подхода недостаточно
Каждый подход имеет слепую зону:
- SAST видит код, но не обязательно видит фактическое поведение и конфигурацию;
- DAST видит реальный внешний эффект, но зависит от покрытия интерфейсов и почти не объясняет внутреннюю причину;
- IAST даёт внутренний runtime-контекст, но только для исполненных сценариев;
- RASP может блокировать часть атак, но не заменяет исправление уязвимости и безопасную разработку.
Практическая стратегия строится слоями: SAST даёт раннюю обратную связь при разработке, DAST проверяет развёрнутое приложение с позиции клиента, IAST уточняет внутренний путь во время тестирования, а RASP при необходимости добавляет защитный контроль в runtime.
Важно также учитывать, что границы между конкретными продуктами могут быть размыты: один инструмент способен сочетать несколько методов. Поэтому при выборе нужно смотреть не только на название категории, но и на фактическую позицию наблюдения, используемые данные и возможную реакцию.
Короткий ответ
SAST анализирует представление программы без её запуска. DAST проверяет работающее приложение снаружи через доступные интерфейсы. IAST наблюдает внутренний путь выполнения во время тестов. RASP тоже работает внутри runtime, но, помимо наблюдения, способен блокировать потенциально опасные операции. Эти подходы не являются взаимоисключающими: они закрывают разные этапы и слепые зоны анализа безопасности.
