Интеграция DAST в CI/CD пайплайн: автоматический поиск уязвимостей

Почему DAST запускают поздно и уязвимости уходят на релиз

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

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

Цена такой экономии — уязвимости в рабочей среде. Находка приходит, когда код уже отдан пользователям, и закрывать её приходится внеплановым выпуском: срочная правка, повторная сборка, ручной прогон затронутых сценариев. Окно между появлением дефекта и его исправлением растягивается на недели, а часть проблем к этому моменту уже видна снаружи.

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

Эффект от поиска уязвимостей на каждой сборке конвейера

Автоматическое сканирование на каждой сборке сжимает окно между появлением уязвимости и её обнаружением с недель до часов. Пока стенд поднимается после выкатки, OWASP ZAP обходит приложение в режиме активного сканирования и складывает отчёт в тот же прогон, что и автотесты. Разработчик получает дефект в контексте своей правки, а не через месяц на приёмке.

Это меняет структуру находок. Доля уязвимостей, пойманных до релиза, обычно растёт с половины до девяти из десяти — остаток приходится на логику доступа, которую сканер не проверяет. Класс отказов, который закрывается полностью: доступные без авторизации маршруты, отсутствующие заголовки безопасности, устаревшие библиотеки с известными дефектами.

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

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

Режимы запуска DAST: сборка, расписание, ручной прогон

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

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

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

Как мы встраиваем DAST в конвейер: этапы работ

Внедрение DAST начинается не со сканера, а с инвентаризации: какие сервисы и стенды проверяем, под какими ролями заходим, какие маршруты критичны для бизнеса. Без этого сканер упирается в форму входа и отдаёт отчёт по одной странице — проверка формально есть, толку нет.

1. Инвентаризация целей. Список адресов, тестовые учётные записи на каждую роль, ограничения по нагрузке и окно запуска, безопасное для стенда.
2. Схема запуска. Короткая проверка идёт на каждое изменение после выката, полная — по расписанию. Обратная связь приходит минутами, а не к концу недели.
3. Настройка сценариев обхода. Вход в систему, продление сессии, обход по спецификации API и обход интерфейса: формы, параметры, скрытые поля, которых в спецификации нет.
4. Отсечение шума. Исключения фиксируем с обоснованием и датой пересмотра, находки делим на подтверждённые и требующие ручной проверки. Иначе отчёт через месяц перестают читать.
5. Порог качества сборки. Блокируют только подтверждённые уязвимости высокого уровня на критичных маршрутах, остальное уходит предупреждением. Порог согласуем с разработкой: слишком строгий быстро отключают.
6. Проверка на контрольных уязвимостях. Подсаживаем на стенд намеренную уязвимость и убеждаемся, что она попала в отчёт. Не попала — правим сценарий, а не доверие к инструменту.
7. Регламент разбора находок. Фиксируем, кто и в какой срок разбирает отчёт, куда уходит задача, как подтверждается закрытие. Отчёт по каждому запуску остаётся в артефактах сборки.

После передачи регламента конвейер работает без нас: новые сервисы добавляются в схему по чек-листу, а порог качества правится в одном месте.

Артефакты внедрения: настройки, схемы, регламенты

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

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

Регламент отдаём вместе с доступами и разбором на реальном прогоне — чтобы профили, исключения и пороги менялись без нас.

Кейс: как разовый аудит стал ежедневной проверкой

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

Что изменили

Сканер OWASP ZAP развернули в режиме автоматического анализа и включили в конвейер сборки: прогон стартует на каждом слиянии в основную ветку. Стенд поднимается с теми же миграциями, что и в проде, обход идёт по карте маршрутов, результат сравнивается с базовой линией — новый дефект виден на фоне уже известных. Критичные находки останавливают сборку, остальные уходят в трекер с привязкой к коммиту и автору правки.

Метрики до и после

• Ручные проверки: раз в квартал → автоматический прогон на каждое слияние и в ночных сборках.
• Время от появления дефекта до обнаружения: две-три недели → часы, в пределах того же дня.
• Доля находок, закрытых до релиза: 55% → 96%; остальное — осознанные исключения с записью в базовую линию.
• Ложные срабатывания: после настройки правил шум снизился примерно втрое, отчёты перестали вычитывать целиком.

Ручной аудит не отменили: он остался для сценариев доступа и логики бизнес-операций, которые сканер не проверяет. Ежедневный прогон закрывает регулярный фон, поэтому внешняя проверка больше не тратит время на очевидное.

Чем DAST отличается от SAST и что запускать первым

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

Порядок подключения задаёт цена обратной связи. Статический анализ отвечает за минуты, поэтому первым ставят его — обязательной проверкой на изменение в ветке. Динамический требует развёрнутого стенда с тестовыми данными и прогоняется дольше, поэтому его выносят из быстрого цикла в ночной запуск и в обязательный шаг перед выпуском.

Приоритет внедрения при ограниченном внимании команды: сначала статический анализ на изменении, затем динамический перед каждым выпуском, затем расширение сценариев на авторизованные роли. Пока проверки не встроены в конвейер, они остаются разовой акцией — а регулярный прогон превращает их в управляемый процесс.

Технические сомнения: шум, вход в систему, тестовые стенды

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

Как сканер проходит авторизацию?

Учётные данные подставляются из хранилища секретов, цепочка редиректов повторяется, сессия удерживается, а при истечении токена вход выполняется заново без ручного участия. Роли берём разные — гость, пользователь, администратор: так ловится и обход контроля доступа, а не только открытые формы.

Что попадёт на тестовый стенд?

Стенд наполняется обезличенной копией базы, доступ ограничен временем прогона и адресами сборочных агентов, после сканирования окружение пересоздаётся. Проверки остаются воспроизводимыми между запусками, а персональные данные в контур не попадают.

Насколько это удлиняет сборку?

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

Обсудим задачу: соберём схему проверок под ваш конвейер

Чтобы разговор был предметным, принесите описание того, как сейчас устроен ваш конвейер. Готовое техническое задание не нужно — достаточно вводных, по которым видно, где динамический анализ (DAST) встроится без остановки выпусков.

• Как запускается сборка и какие окружения поднимаются автоматически — от тестового стенда до предпромышленного.
• Где логично поставить проверку: сразу после развёртывания на стенд, по расписанию вне рабочих часов или вручную перед выпуском.
• Какие сервисы поднимаются в изолированной среде и нужны ли им внешние зависимости — базы, очереди, сторонние сервисы.
• Есть ли тестовые учётные записи и данные, чтобы проверка проходила авторизацию, а не упиралась в форму входа.
• В каком виде команде удобно получать результат — задачей в трекере, файлом в артефактах сборки или сводкой на панели.
• Кто разбирает найденное и по какому порогу сборка считается проваленной: единичная находка или их доля от общего числа путей.

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