Между кодом и продом: место DAST в SSDLC

Последние два года DAST на схемах DevSecOps рисуют одинаково: прямоугольник после deploy, внутри — ZAP или Nuclei. Сканер получил адрес стенда, вернул отчет, джоба позеленела. Только по зеленой джобе не понять, что проверено. Скан вполне мог закончиться без серьезных находок, потому что до них просто не дошел.

Меня зовут Даниил Слюсарь, я руковожу разработкой продуктов AppSec в Positive Technologies. Разберем, что внутри этого прямоугольника, какие задачи он решает, где ему место в конвейере и почему без него полноценной защиты не получится.

Через веб заходят в инфраструктуру, и делают это часто. В нашем свежем исследовании установлено, что проникновение в 36% случаев начиналось с веб-приложения на периметре. У госсистем есть и формальный повод: с 1 марта 2026 года действует приказ ФСТЭК № 117, и критическую уязвимость теперь нужно устранить за 24 часа, уязвимость высокого уровня — за 7 дней.

Кто что видит

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

Код есть, но уязвимость не в нем

Возьмем обычное веб-приложение: SPA-фронтенд и API. Запросы параметризованы, пароли хешируются, зависимости свежие, SAST и SCA зеленые. Все это отдает Caddy, и при деплое в его конфиге корень статики указали на каталог выше нужного:

app.example.ru {
    handle_path /api/* {
        reverse_proxy backend:8080
    }
    handle {
        root * /srv/app        # а нужно /srv/app/dist
        file_server
    }
}

Вместо сборки из dist Caddy теперь раздает весь каталог приложения — с .env, где лежит пароль от базы, и .git с историей кода:

GET /.env         → 200  DB_PASSWORD=…  SECRET_KEY=…
GET /.git/config  → 200  [remote "origin"] url = …

В исходниках приложения этой утечки нет. Обновлять Caddy смысла нет — ошибка в конфиге. Ее можно поймать на ревью Caddyfile, если до него дойдут руки. DAST же после деплоя просто запросит эти файлы у сервера. На нашем стенде PT BlackBox нашел .env и четыре файла из .git: config, HEAD, refs/heads/master и logs/refs/heads/master.

Из той же серии: отладочная консоль фреймворка, доступная снаружи; открытые служебные эндпоинты /actuator; сервис, к которому можно пройти мимо API-шлюза; X-Forwarded-For, который прокси пропускает от клиента, а приложение ему верит. Один 200 OK здесь ничего не доказывает — смотреть нужно на поведение.

Когда кода нет совсем: сканируем периметр

С коробочным ПО — корпоративным мессенджером, CMS, VPN-порталом — исходников для SAST нет. SCA нужен состав компонентов, а его вендор дает не всегда. Остается смотреть снаружи: DAST найдет известную уязвимость по HTTP, WAF может ограничить попытки ее эксплуатировать.

Пример — TrueConf Server. В августе 2025 года Никита Петров из PT SWARM нашел в нем цепочку из трех уязвимостей: обход аутентификации (BDU:2025-10114, CVSS 3.1 — 7,5), чтение защищенных файлов через Path Traversal (BDU:2025-10115, 7,5) и внедрение команд ОС (BDU:2025-10116, 9,8). Вместе они дают выполнение кода на сервере без учетной записи. Эксплойт существует, в БДУ уязвимости помечены как связанные с инцидентами. Вендор сообщил об исправлениях в версиях 5.3.7, 5.4.6 и 5.5.1.

Только обновиться мало — надо убедиться, что обновление дошло. Обновили не тот узел, откатились из бэкапа, забыли про тестовый сервер, торчащий в интернет, — все это случается. Снаружи, без агента и учетки на хосте, такое и проверяет DAST.

Мы просканировали стенд с TrueConf Server 5.5.0, уязвимым ко всем трем. Версию веб-интерфейс выдает сам: админка грузит /admin-area/bundle.js?version=5.5.0.13828~debian12. Сработали все три проверки — BDU:2025-10114, BDU:2025-10115 и BDU:2025-10116. Скан занял две с половиной минуты.

Коробочное ПО так и проверяют: после каждого обновления и по расписанию. Скан обращается к самим уязвимым функциям. Если администратор уже отчитался о патче, а опасное поведение осталось, это будет видно.

Что должно быть внутри сканера

Сканер работает в два шага: собирает поверхность атаки — эндпоинты, методы, параметры — и проверяет ее. Эндпоинты он берет из краулера, API-схемы или записанного трафика. Если эндпоинта нет ни в одном из них, сканер его не проверит. Уязвимость в таком эндпоинте станет пропуском (false negative), и по отчету этого не заметить: эндпоинта там просто нет.

Покрытие: современный веб — это SPA

Классический краулер открывает страницу, собирает <a href> и <form>, переходит по ним — и так по кругу. В SPA на React или Vue, например в личном кабинете интернет-магазина, этот номер не пройдет. Клик по аватару открывает меню, в меню — «Настройки», там вкладки, во вкладке кнопка смены фото, и только она шлет PUT /api/profile. В исходном DOM этих элементов не было, URL не менялся, запрос ушел в фоне. Ссылки, по которой до него можно дойти, нет.

Обходить приходится состояния интерфейса. Их экспоненциально много, а понять по DOM, новое это состояние или уже виденное, непросто. Подробно мы разбирали это в статье «Сколько страниц на SPA». Если коротко, состояние у нас — множество отпечатков интерактивных элементов, доступных прямо сейчас. URL в него не входит, отпечаток устойчив к сгенерированным id, числам и координатам. Действия в графе обхода — отдельные узлы: кнопка логина есть в пятидесяти состояниях, а узел у нее один.

Раньше на SPA без API-схемы и HAR краулер видел почти одну статику. На Rocket.Chat он не мог загрузить даже страницу входа, и покрытие было нулевым. Теперь там краулер собирает 93% поверхности. Меньше всего получилось на тестовом экземпляре YouTrack — 65%, больше всего на Juice Shop — 97%. Единицей поверхности мы считали сочетание метода, пути, формы тела запроса и набора параметров. Пути нормализовали, чтобы случайные идентификаторы в URL не раздували счет. Эталоном служили API-схемы и HAR, собранные вручную. Речь только о покрытии поверхности, долю найденных уязвимостей считают отдельно.

И все же краулер — самый хрупкий источник поверхности. Дополняйте его тем, что в пайплайне уже есть: OpenAPI-схемой, HAR из e2e-тестов на Playwright или Cypress (валидные запросы для пройденных сценариев), перебором директорий.

Пример: OWASP Juice Shop

OWASP Juice Shop — SPA на Angular с REST API и намеренными уязвимостями, часть которых доступна только после входа. В сентябре 2026 года на внутреннем стенде мы прогнали по Juice Shop 20.2.0 два сканера с авторизацией, по одному разу каждый: PT BlackBox 3.3 входил через форму /#/login, ZAP 2.17 работал в режиме Authenticated scan с AJAX Spider.

Сначала о счетчиках. ZAP группирует алерты, PT BlackBox считает каждое срабатывание, так что «48 против 14» о числе уязвимостей ничего не говорит. Уровни опасности в таблице взяты из отчетов самих сканеров, и в лоб их тоже сравнивать не стоит: каждый сканер расставляет уровни по-своему. Например, отсутствие CSP есть в обоих отчетах, но ZAP относит его к среднему уровню, а PT BlackBox — к низкому, поэтому в строке среднего уровня у PT BlackBox его нет. Честнее сравнивать конкретные уязвимости: кто что нашел и подтвердил.

SQL-инъекцию в поиске, GET /rest/products/search?q=, нашли оба: эндпоинт доступен без входа и виден в JavaScript-бандле. SSRF в POST /profile/image/url и XXE в POST /file-upload есть только в отчете PT BlackBox, и обе подтверждены эксплуатацией. Небезопасная загрузка файлов — на фотостене, POST /rest/memories.

Немалая часть поверхности спрятана за логином. PT BlackBox собрал 20 запросов к API, меняющих данные (POST, PUT, DELETE), и до многих из них добраться можно только через интерфейс после входа: привязка и удаление карты (/api/Cards), адрес доставки, отзыв о товаре, фотостена (/rest/memories), аватар по ссылке (/profile/image/url), вложение к жалобе (/file-upload), настройка 2FA. Сколько из этого прошел ZAP, по его отчету не понять: в нем только алерты и статистика, а списка всех отправленных запросов нет. Поэтому по 120 минутам и 71 тыс. запросов нельзя сказать, что ZAP работал впустую: он мог покрыть и больше поверхности, просто без находок. Чтобы сравнить покрытие честно, нужно выгрузить из обоих сканеров списки запросов и сверить их с одним эталоном.

ZAP умеет обходить SPA, сканировать с авторизацией и встраиваться в CI. Наш прогон — результат конкретных настроек на одном стенде, и выносить по нему приговор инструменту не стоит. Сравнивайте на своих стендах: прошел ли сканер вход, какие методы и пути нашел, какие уязвимости подтвердил, сколько времени ушло. И прикиньте, кто будет обновлять проверки и поддерживать сценарии входа.

Авторизация

Без входа сканер видит только публичную часть приложения. Серьезные уязвимости бывают и там, но все, что открывается после входа, — личный кабинет, настройки профиля, админка — остается за бортом. А вход в настоящем приложении редко сводится к форме с логином и паролем: это SSO с редиректами через внешний IdP, выбор организации, CSRF-токены на каждом шаге. Сканер должен уметь проходить такой вход по шагам. Даже простую форму в SPA сначала надо увидеть: в HTML, который отдает Rocket.Chat, формы входа нет, ее рисует JavaScript.

Еще сессия может истечь посреди скана, и тогда остаток скана пройдет без входа. PT BlackBox пока не умеет это замечать и входить заново, поэтому на стенде лучше задать срок жизни сессии больше, чем длится скан.

С ролями своя история. Скан под каждой ролью покрывает ее функции, но нарушений доступа так не найти. Может ли одна роль выполнить чужое действие или получить чужой объект, PT BlackBox пока не проверяет. Это остается за автотестами на матрицу доступа и пентестом.

Насколько важен вход, мы увидели, когда сравнили PT BlackBox 3.2 и 3.3 на одной версии Juice Shop. Новый краулер поднял число находок с 7 до 10, новая авторизация поверх него — с 10 до 48. SSRF и XXE из разбора выше появились только со входом.

Скан должен заканчиваться

У джобы в CI есть таймаут, у стенда — ресурсы. Сканер, который обходит SPA бесконечно, в CI бесполезен: ему нужны условие остановки и лимиты. Наш краулер останавливается, когда в графе обхода не осталось невыполненных действий, или по настраиваемому лимиту времени — в замерах покрытия выше бывало и то и другое. Весь скан Juice Shop вместе с проверками занял 22 минуты.

Одна из ловушек видна в отчете ZAP по Juice Shop: больше половины уникальных URL в находках приходится на опрос Socket.io. В режиме long polling параметры t= и sid= меняются, и каждый запрос выглядит новым URL. Почему ZAP пропустил SSRF и XXE, по отчету не понять: сколько времени ушло на опрос, там не видно. Если гоняете ZAP по SPA с веб-сокетами, проверьте нормализацию URL и исключения.

Еще сканер должен узнавать дубликаты страниц и однотипные элементы, не перегружать стенд и не трогать эндпоинты, которые шлют рассылку, проводят платеж или что-то удаляют. И результат должен воспроизводиться, иначе порог в gate превращается в лотерею.

Чем доказана находка

Находки бывают разной силы. Баннер с номером версии — только повод проверить известную уязвимость. Доказательство — результат эксплуатации: выполнился скрипт (XSS), пришел обратный запрос (слепая SSRF), прочитался файл (XXE).

В Juice Shop XXE подтвердилась так: сканер загрузил в POST /file-upload XML с внешней сущностью, и в ответе пришло содержимое /etc/passwd.

<?xml version="1.0"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<foo>&xxe;</foo>

С SSRF по ответу приложения ничего не видно. Сканер передал в POST /profile/image/url ссылку на свой OAST-домен, и находку подтвердил обратный запрос от стенда. Отсюда и ограничение: если у стенда нет выхода до OAST-домена сканера, обратный запрос не дойдет и находки не будет.

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

Где DAST в конвейере

Чем ближе к проду, тем шире скан:

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

Сузить скан помогают профиль и API-схема сервиса. Со сканом по изменениям есть подвох: дифф OpenAPI покажет, что поменялся контракт, но реализацию, переписанную при той же схеме, не заметит. Так что полного скана перед релизом ограниченный скан на MR не отменяет.

Чтобы этап прижился, нужны четыре правила.

1. Сканируйте образ, который поедет в прод: «build once, promote». И помните про окружение — тот же образ за другим прокси и с другими правами ведет себя иначе.

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

3. Блокируйте только по тому, чему доверяете. Порог «есть High» работает, если находки этого уровня воспроизводятся. На Juice Shop он сработал бы на SQL-инъекцию, SSRF и XXE, а замечания к CSP его бы не тронули. У каждого исключения должны быть владелец и срок пересмотра, иначе порог начнут обходить.

4. Сводите результаты в одно место. SARIF из DAST кладите в ту же ASOC/ASPM, что и результаты SAST и SCA, и привязывайте к сервису и версии сборки. Склеивать находки разных слоев можно, только когда понятно, что это одна и та же уязвимость.

Как встроить в CI/CD

Для CI есть открытый скрипт интеграции BlackBox-CI-CD-script. Он написан на Python и работает через API сканера: создает сайт в сканере, если его еще нет, запускает скан, ждет окончания, сохраняет отчет, печатает JSON со сводкой и возвращает код выхода для gate. Работает и с облаком, и с on-prem.

Ниже минимальный пример для GitLab CI. Джоба deploy_stage выкатывает стенд, следующая сканирует его со входом в приложение и сохраняет отчет.

ptbb_dast_scan:
  stage: dast
  needs: [deploy_stage]
  image: python:3.11-slim
  timeout: 2h
  variables:
    PTBB_CI_REF: "3.3"                       # фиксируем версию скрипта
    PYTHONPATH: "/opt/blackbox-ci/python-deps"
  before_script:
    - apt-get update -qq && apt-get install -y -qq --no-install-recommends git > /dev/null 2>&1
    - git clone --depth 1 --branch "${PTBB_CI_REF}" https://github.com/PT-BlackBox/BlackBox-CI-CD-script.git /opt/blackbox-ci
  script:
    - mkdir -p ${CI_PROJECT_DIR}/ptbb-reports
    - |
      DAST_EXIT=0
      python /opt/blackbox-ci/main.py \
        --blackbox-url "${PTBB_URL}" \
        --blackbox-api-token "${PTBB_TOKEN}" \
        --target-url "${TARGET_URL}" \
        --auto-create \
        --auth-profile "${PTBB_AUTH_PROFILE}" \
        --previous stop \
        --shared-link \
        --report-dir ${CI_PROJECT_DIR}/ptbb-reports \
        --report-template html \
        --report-locale ru \
      || DAST_EXIT=$?
    - |
      case "${DAST_EXIT}" in
        0) echo "OK — scan completed" ;;
        3) echo "WARN — score below threshold" ;;   # только с --fail-under-score
        *) echo "ERROR — code ${DAST_EXIT}"; exit ${DAST_EXIT} ;;
      esac
  artifacts:
    when: always
    paths: [ptbb-reports/]
    expire_in: 30 days
  allow_failure: true
  rules:
    - if: '$CI_COMMIT_BRANCH'

- PTBB_URL, PTBB_TOKEN и PTBB_AUTH_PROFILE — адрес сканера, API-токен и UUID профиля входа. Они лежат в переменных CI, токен — с флагом Masked. Если включить еще и Protected, токен получат только защищенные ветки и теги, а правило в примере запускает джобу на любой ветке. Тогда либо снимите Protected, либо ограничьте rules защищенными ветками.

- TARGET_URL — адрес стенда, который выкатила deploy_stage. Его можно передать через dotenv-артефакт.

- GROUP_UUID — группа сайтов в сканере. В примере ее нет: скрипт сам читает переменную CI с таким именем, если она задана. Если у учетки одна группа, переменная не нужна, если групп несколько — без нее скрипт завершится с ошибкой.

- --auto-create заводит сайт в сканере, если сайта с таким адресом еще нет. Поэтому UUID сайта джобе знать не нужно. Облачному сканеру стенд должен быть доступен из интернета, а владение сайтом нужно подтвердить, поэтому внутренние стенды сканируют on-prem.

- --auth-profile привязывает к сайту профиль входа перед сканом. Профиль один раз заводят и проверяют в интерфейсе сканера: как пройти вход и как понять, что сессия жива (на момент старта). Без профиля сканер проверит только то, что доступно без входа. Для простой формы входа профиль можно не заводить: --auth-data возьмет настройки из файла, а пароль — из переменной AUTH_PASSWORD.

- --previous stop решает, что делать, если сайт уже сканируется: идущий скан останавливается, запускается новый. По умолчанию стоит fail, и джоба падает. На общем стенде с stop параллельные пайплайны будут останавливать сканы друг друга, а wait дождется окончания чужого скана.

- --shared-link добавляет ссылку на результаты в JSON, который скрипт печатает в лог джобы. По этой ссылке результаты откроет разработчик без учетки в сканере.

- --report-dir, --report-template и --report-locale задают папку, формат и язык отчета. Папка уходит в артефакты джобы. Для DefectDojo и других ASOC вместо html нужен sarif.

- Если у on-prem-сервера самоподписанный сертификат, перед вызовом main.py выполните export SSL_CERT_FILE="$PTBB_CA_CERT", где PTBB_CA_CERT — переменная CI типа File с сертификатом CA: системные CA скрипт не использует, а --ignore-ssl отключит проверку сертификата целиком.

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

- 0 — скан завершился. Джоба зеленая.

- 3 — общая оценка отчета ниже порога. Этот код бывает только с флагом --fail-under-score, о нем ниже. В примере на нем джоба лишь пишет предупреждение и остается зеленой.

- 1 и любой другой код — сбой: скан не дошел до конца, сканер недоступен, токен не подошел. Джоба падает, но из-за allow_failure: true GitLab помечает ее желтым, а не красным, и пайплайн идет дальше.

В таком виде этап ничего не блокирует: релиз пройдет, даже если скан сломался.

Чтобы этап блокировал релиз, добавьте в вызов --fail-under-score 7. Сканер ставит отчету общую оценку от 1 до 10: чем меньше опасных находок, тем она выше. TrueConf с RCE из примера выше получил 1. Если оценка ниже порога, скрипт вернет 3. Порог 1 не сработает никогда: ниже единицы оценки не бывает. Семерка взята для примера — подберите порог по своей статистике. Затем поправьте пример: в ветке 3) замените echo на exit 3, чтобы джоба падала, уберите allow_failure, чтобы ее падение останавливало пайплайн, и ограничьте rules релизными ветками. На ревью-стендах этап лучше оставить информационным.

Есть два случая, когда код выхода говорит не то, чего ждешь:

- Если у отчета нет оценки (в JSON "score": null), порог не проверяется и скрипт возвращает 0. Так бывает, например, с флагом --no-wait: скрипт запускает скан и не ждет результата.

- Скан, который не дошел до статуса FINISHED, скрипт считает сбоем: возвращает 1 и не сохраняет отчет в ptbb-reports/, ссылка на скан будет в логе джобы. Так бывает, например, когда скан остановил следующий пайплайн через --previous stop. Без allow_failure такой пайплайн покраснеет, хотя дело не в находках.

На ревью-стендах можно сканировать не все приложение, а только измененный сервис. Для этого заведите в сканере отдельный профиль скана и API-схему этого сервиса и передайте их UUID в --scan-profile и --api-schema. Если одного порога по оценке мало, свои условия можно проверять по JSON, который печатает скрипт, — как это сделать, описано в документации скрипта интеграции.

Чего DAST не умеет

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

Сканер плохо проходит API со сложным контекстом. Если эндпоинт принимает только согласованную цепочку идентификаторов companyId → projectId → userId, со случайными значениями сканер до него не доберется. Валидные запросы для записанных сценариев дает HAR из e2e-тестов, но идентификаторы и токены в нем должны оставаться действительными к началу скана.

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

Чек-лист

1. На стенд деплоится тот же образ, что поедет в прод, а различия в настройках окружения учтены.

2. Под каждую роль есть тестовая учетка, секреты лежат в переменных CI.

3. Профиль скана настроен один раз: вход с проверкой сессии, исключения для опасных эндпоинтов, число параллельных потоков под ресурсы стенда.

4. Поверхность собирается из краулера, OpenAPI-схемы и HAR из e2e-тестов.

5. Под каждой ролью найденные и проверенные операции сверены с OpenAPI, исключения и недоделанное из-за таймаута отмечены.

6. На MR-стендах — ограниченный скан в информационном режиме, на релиз-кандидате — полный с порогом по находкам, которым вы доверяете, на проде и периметре — регулярный.

7. SARIF уходит в ASOC и привязывается к сервису и версии сборки.

8. После каждого обновления коробочного ПО — внеплановый скан.

Вместо заключения

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

Место в конвейере — полдела. На Juice Shop две из трех серьезных уязвимостей, SSRF и XXE, нашлись в личном кабинете. Поэтому прежде чем верить зеленой джобе, проверьте, что сканер вошел и дошел до личного кабинета, а не остановился на странице логина.

Попробовать PT BlackBox можно в облаке на bbs.ptcloud.ru, а если нужен on-prem, устроим пилот. А в комментариях расскажите, как устроено ваше DAST-тестирование и что заставило его отключить, если отключали.