Анализ защищенности веб-ресурсов: выбор сканеров уязвимостей кода

IAST наблюдает исполнение кода и поток данных в работающем приложении.

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

Архитектура сканеров: код, протокол и время исполнения

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

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

IAST устанавливает агент в среду исполнения. Инструмент анализирует потоки данных и вызовы кода в реальном времени, когда тест проходит через приложение. Метод соединяет наблюдение во время исполнения с контекстом исходного кода.

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

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

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

Выбор метода по архитектуре приложения

Решение строится по узлам приложения, а не по списку функций коммерческого продукта.

1. Есть исходный код и повторяемый деплой. Начните с SAST. Для регулярной проверки запускайте анализ изменённых файлов на каждом коммите, а полный анализ codebase оставляйте для ночного или планового прогона. Так тяжёлый статический анализ не блокирует каждое изменение, но сохраняет полный охват.

2. Есть работающий HTTP-сервис или API. Добавьте DAST. Сканеру нужны реальные маршруты, тестовые учётные записи и состояние приложения. Анонимный прогон проверяет только публичную поверхность. Для проверки авторизации нужны отдельные роли и сценарии с ограниченными правами.

3. Runtime поддерживает инструментацию. Используйте IAST на контролируемой тестовой среде. Агент покажет, доходит ли значение до опасного вызова в конкретной конфигурации. Ограничение остаётся прямым: непротестированный маршрут не создаёт наблюдаемого потока.

4. Значительная часть стека состоит из внешних компонентов. Подключите SCA. Анализируйте манифесты зависимостей, lock-файлы, образы контейнеров и SBOM. Результаты SCA следует обрабатывать отдельно: срочность обновления зависимости и риск дефекта в коде команды измеряются разными шкалами.

SAST полезен для legacy-кода, где динамическое покрытие маршрутов низкое. Проблема здесь в качестве правил: большой объём ложноположительных срабатываний быстро превращает проверку в шум. Нужны базовый отчёт, приоритет по проверяемости пути и отдельный процесс подтверждения находок.

DAST точнее отражает поведение развернутой системы. Он видит заголовки, cookies, перенаправления, ошибки конфигурации и фактические ответы API. Но DAST зависит от полноты инвентаря маршрутов. Если endpoint отсутствует в спецификации, OpenAPI или сценариях тестирования, сканер может никогда его не вызвать.

IAST оправдан там, где обычный black-box-тест возвращает симптом без понятного пути. Сценарий с агентом связывает вход, межсервисный вызов и опасный участок. При этом агент способен изменить нагрузку, а внедрение в production добавляет новый класс рисков.

Выбор по классу инструмента без проверки достижимого кода даёт отчёт о шаблоне. Выбор по достижимому коду даёт основание для инженерного решения.

Конвейер обнаружения уязвимостей в CI/CD

Сканеры нужно распределить по этапам поставки. Каждый этап получает собственный артефакт, контекст и правило обработки.

1. Зафиксируйте поверхность приложения. Соберите инвентарь доменов, маршрутов, API, ролей, форм, заголовков и точек доверия. Укажите, какие среды можно тестировать. Определите тестовые аккаунты, синтетические данные и допустимые действия сканера.

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

3. Проверяйте зависимости отдельным шагом. SCA анализирует сторонние пакеты и образы. Обновляйте сведения об уязвимостях, фиксируйте исключения с владельцем, сроком пересмотра и причиной. Исключение без срока действия превращается в постоянный обход проверки.

4. Разворачивайте тестовую сборку для DAST. Сначала проверьте доступность приложения и корректность состояния. Затем выполняйте пассивный анализ трафика и только после этого активные проверки. Для аутентифицированных API подготовьте отдельные токены или учётные записи с минимальными правами.

5. Подключайте IAST к тестовым сценариям. Агент должен работать в поддерживаемой версии runtime. Учитывайте накладные расходы на CPU, память и задержку. Результаты IAST полезнее сопоставлять с DAST-находкой по тому же маршруту и входному параметру.

6. Ведите находки до подтверждения и исправления. Для каждого результата зафиксируйте маршрут, вход, доказательство, затронутый компонент, статус и результат повторной проверки. Дефект считается закрытым после успешного retest, а не после внесения изменения в репозиторий.

7. Продакшен оставляйте под контролем. Активное DAST-тестирование допустимо после согласования, с ограничением скорости запросов, резервной точкой восстановления и механизмом остановки. Массовый полный прогон без подготовки данных и учётных записей создаёт риск деградации и блокировок.

Бенчмарк: измерять точность и стоимость на своём коде

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

Методика сравнения требует фиксированных условий:

1. Используйте один и тот же коммит, версии зависимостей и конфигурацию тестовой среды.

2. Применяйте одинаковые тестовые данные и сценарии авторизации.

3. Запускайте несколько сопоставимых прогонов. Единичный результат не отделяет устойчивую находку от случайного срабатывания.

4. Проверяйте каждое предупреждение вручную. Автоматическая классификация полезна для сортировки, но не заменяет подтверждение.

5. Фиксируйте версии сканеров, правила, исключения и изменившиеся настройки.

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

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

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

OWASP ZAP в автоматизированном контуре

OWASP ZAP относится к DAST-сканерам и распространяется с открытым исходным кодом. Инструмент поддерживает ручную работу через прокси и автоматизированные сценарии в CI/CD. Для веб-ресурса это полезный контроль внешнего поведения приложения.

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

В CI/CD ZAP обычно запускают после деплоя тестовой версии. Конфигурация фиксирует адреса, методы, аутентификацию, ограничения скорости и список разрешённых активных проверок. Отчёт сохраняется как артефакт сборки вместе с версией приложения и конфигурацией сканирования.

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

Для API нужны корректные схемы запросов, токены и понятное состояние ресурсов. Один административный токен не проверяет разграничение доступа. Для анализа авторизации создаются отдельные роли и сценарии, которым запрещены операции с чужими объектами.

ZAP не указывает точную строку исходного кода с уязвимостью. Отчёт содержит наблюдаемое поведение, HTTP-обмен, маршрут и параметры. Сопоставление выполняют с журналами приложения, трассировкой, SAST или IAST. Без такого сопоставления DAST-отчёт остаётся техническим индикатором, а не готовым диагнозом.

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

Правовой контур, стандарты и ограничения

OWASP Top 10 служит признанной классификацией критических рисков веб-приложений. Редакция 2021 года поставила Broken Access Control на первое место. Обновление 2025 года продолжило эту линию классификации. Находки сканеров полезно приводить к категориям OWASP, но такое сопоставление не измеряет полноту покрытия.

Одна категория может соответствовать нескольким маршрутам и способам эксплуатации. Одна уязвимость также может проходить через несколько категорий. Поэтому отчёт с привязкой к OWASP Top 10 дополняйте данными о достижимости, подтверждении и исправлении.

PCI DSS требует регулярного тестирования защищённости. Наличие DAST в CI/CD не закрывает все требования стандарта: остаются организационные измерения, управление доступом, защита данных и работа с рисками. Сканер закрывает техническую часть обнаружения дефектов, а не весь объём контроля.

Доступ к чужому веб-приложению требует письменного разрешения владельца. Для тестирования стороннего ресурса отсутствие согласия может привести к ответственности по ст. 272 УК РФ. Формального разрешения недостаточно: границы тестирования должны быть зафиксированы.

Внутренняя спецификация допустимого сканирования должна содержать:

• перечень доменов, IP-адресов, API и маршрутов;
• типы активных проверок и запрещённые операции;
• разрешённые среды, окна тестирования и лимиты скорости;
• тестовые учётные записи, роли и правила обработки данных;
• контакты владельца сервиса и механизм немедленной остановки;
• порядок очистки тестовых данных и фиксации инцидентов.

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

Порядок ввода сканеров в эксплуатацию:

1. Сопоставьте SAST, SCA, DAST и IAST с компонентами приложения.

2. Соберите инвентарь маршрутов, ролей и зависимостей.

3. Зафиксируйте baseline по точности, покрытию, времени триажа и накладным расходам.

4. Разверните активное DAST и IAST в тестовой среде.

5. Переведите подтверждённые находки в единый трекер с retest.

6. Согласуйте отдельный режим для production и зафиксируйте исключения.

7. Пересматривайте бенчмарк после изменений архитектуры, правил и зависимостей.

Рабочая конфигурация обычно состоит из SAST до merge, SCA для сторонних компонентов, DAST после тестового деплоя и IAST там, где runtime позволяет получить достоверный поток данных. У каждого метода остаётся слепая зона. Утверждение о защищенности веб-ресурса должно опираться на собственный бенчмарк, подтверждённые находки и закрытые исключения. Проценты без такой базы остаются маркетинговым шумом.