SAST и DAST в Zero Trust: как проверить безопасность кода и приложения

«Мы давно перестали думать о безопасности как о периметре — теперь мы строим её в самом приложении. И только сочетание статического анализа кода (SAST) и динамического тестирования приложения (DAST) позволяет проверить, что политики контроля доступа из концепции Zero Trust действительно работают, когда их никто не видит, кроме самого приложения»

Сдвиг периметра: код становится границей доверия

Концепция безопасности, построенной вокруг «доверенной» внутренней сети — VLAN, внутренних IP.
Происходит смещение точки контроля: защищать нужно не сетевую зону, а каждую транзакцию, каждый вызов API внутри приложения. Каждая операция с данными должна проходить независимую проверку прав — вне зависимости от источника запроса. Это и есть суть Zero Trust в применении к прикладному уровню.

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

SAST: анализ «чертежей» безопасности

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

Что именно проверяет SAST

Анализатор строит модель кода, анализируя синтаксис, потоки данных и граф вызовов функций. Он ищет паттерны, нарушающие базовые правила безопасной разработки. Например:

Использование потенциально опасных функций (eval, system, exec).
Конкатенация строк для формирования SQL-xапросов (риск инъекций).
Открытие файлов по пользовательскому пути без нормализации (path traversal).
Хранение секретов (паролей, ключей) в коде или конфигах в открытом виде.
Использование устаревших или слабых криптографических алгоритмов.

SAST действует как линтер для безопасности, помогая устранить грубые ошибки, которые легко пропустить при code review. Это форма проверки «намерений» разработчика по написанному коду.

Фундаментальные ограничения статического анализа

Главный недостаток SAST в контексте Zero Trust — он не видит контекста выполнения и реального поведения приложения.

Незнание окружения и конфигурации: SAST не знает, как сконфигурирован сервер приложений, API-(шлюз или база данных. Он не видит, какие заголовки безопасности (CSP, HSTS) установлены, включён ли WAF.
Слепота к бизнес-логике и правам доступа: Анализатор может пометить метод deleteUser() как опасный. Но он не способен проверить, вызывается ли этот метод только после многофакторной аутентификации и проверки сложной ролевой модели. Для SAST это просто функция, которая потенциально может удалить данные.
Неспособность обнаружить ошибки контроля доступа: SAST не сможет найти уязвимость, когда пользователь может изменить параметр id в запросе /api/orders/{id} и получить доступ к чужому заказу (BOLA). Код метода getOrder() технически корректен, ошибка кроется в отсутствии проверки соответствия ID заказа текущему пользователю на уровне бизнес-логики.

SAST гарантирует, что код написан без очевидных уязвимостей, но не гарантирует, что работающее приложение будет безопасным. Это проверка «чертежей», но не «испытаний готовой конструкции».

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

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

Как работает DAST и что он находит

Инструмент автоматически исследует приложение: перебирает эндпоинты, отправляет различные, в том числе искажённые, данные, подменяет заголовки и параметры сессий. Его цель — выявить уязвимости, которые проявляются только во время выполнения.

Ошибки контроля доступа (BOLA, BFLA): Именно то, что не видит SAST. DAST, меняя ID объекта в запросе, может обнаружить, что система возвращает чужие данные или разрешает операции.
Проблемы конфигурации сервера: Раскрытие служебных файлов (.git, .env), директорий, отладочной информации в ошибках, отсутствие важных заголовков безопасности.
Уязвимости, зависящие от состояния: Неправильная обработка сессий, возможность повторного использования токенов, уязвимости типа CSRF, которые требуют анализа взаимодействия нескольких запросов.
Логические уязвимости бизнес-процесса: Например, возможность дважды применить один промокод, изменить итоговую сумму оплаты на стороне клиента или обойти лимиты.

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

Сложности и настройка динамического анализа

Для эффективной работы DAST требуется:

Рабочее окружение: Развёрнутое приложение в среде, максимально приближённой к продуктивной (staging).
Данные для аутентификации: Набор корректных учётных записей с разными ролями для тестирования контроля доступа.
Описание интерфейсов: Для сложных API полезно предоставить DAST спецификацию OpenAPI/Swagger для более полного покрытия.
Исключение деструктивных тестов: Настройка инструмента на избегание тестов, которые могут привести к удалению данных или нарушению работы в тестовой среде.

Современные DAST-решения умеют автоматически обрабатывать сложные сценарии входа (OAuth2, JWT, формы с CAPTCHA), что снижает трудозатраты на настройку.

Практическое взаимодействие SAST и DAST в жизненном цикле разработки

Использовать эти инструменты как альтернативы — ошибка. Они дополняют друг друга на разных этапах, создавая многоуровневую защиту.

Этап	SAST	DAST	Цель этапа
Разработка / Коммит	Выполняется в IDE или при пуше в репозиторий. Блокирует коммит с критическими уязвимостями.	Не выполняется	Предотвратить попадание шаблонных ошибок в код.
Сборка (CI)	Выполняется как часть пайплайна. Провал сборки при высокорисковых находках.	Не выполняется	Гарантия чистоты кодовой базы перед сборкой артефакта.
Развертывание в Staging	Не выполняется	Выполняется автоматически после успешного развертывания.	Проверить поведение собранного приложения в реальных условиях, выявить логические и конфигурационные уязвимости.
Релиз в Production	Не выполняется	Успешный проход DAST — обязательное условие для релиза.	Исключить риск развертывания приложения с уязвимостями контроля доступа.

Замкнутый цикл улучшения безопасности

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

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

DAST выступает не только как проверка, но и как источник данных для обучения и улучшения статических анализаторов и процессов разработки.

Почему без DAST не может быть полноценного Zero Trust

Концепция Zero Trust декларирует принцип «никогда не доверяй, всегда проверяй». SAST проверяет намерения, заложенные в код. Но окончательным арбитром, действительно ли приложение «проверяет каждый запрос», является DAST.

Только динамическое тестирование может дать ответ на ключевые вопросы:

Можно ли, имея валидный токен пользователя A, получить доступ к данным пользователя B?
Защищены ли административные интерфейсы от доступа с обычными правами, даже если прямой ссылки на них нет?
Не раскрывает ли приложение в ошибках или метаданных информацию, которая может упростить атаку?
Эффективны ли настроенные политики CORS и другие механизмы контроля доступа на уровне приложения?

Без регулярного DAST-сканирования внедрение Zero Trust остаётся теоретическим. Вы не можете быть уверены, что сложная ролевая модель, микросервисная архитектура и распределённые транзакции действительно защищены так, как это задумано в коде и документации.

Итог: SAST как базовая гигиена, DAST как проверка на прочность

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

DAST, это инструмент проверки системы в сборе. Он моделирует поведение недоверенного окружения и проверяет, выдерживает ли приложение это давление. Его место — в пайплайне поставки, перед каждым релизом, в руках DevOps и специалистов по безопасности.

В контексте современной разработки, где приложение само становится периметром, отказ от DAST означает слепую веру в то, что все политики доступа, заложенные в коде, работают идеально. Сочетание SAST и DAST, это практическая реализация принципа Zero Trust для прикладного уровня: не доверяй коду на слово, проверь, как он ведёт себя в бою.