Автоматизированный DAST на базе ИИ сокращает ручную настройку и выявляет уязвимости для эксплуатации

В этом интервью для Help Net Security Джони Клипперт, генеральный директор StackHawk, рассказывает о том, что определяет полноту охвата DAST в 2026 году и почему завершение сканирования не равно безопасности. Она объясняет, как DAST-тестирование на основе искусственного интеллекта автоматизирует обнаружение поверхности атаки, поддерживает тестирование бизнес-логики на предпродакшене и сокращает ручную настройку, которая ранее сдерживала внедрение. Клипперт также описывает, как организации могут внедрить тестирование в рантайме без инструментирования продакшен-систем.

Команды часто обманывают себя, измеряя охват через завершение сканирования: «мы просканировали наше приложение, мы защищены». Но вы не можете измерить охват, если не знаете свою поверхность атаки, и эта видимость должна исходить из вашего источника истины ещё до начала тестирования. Хороший охват DAST в 2026 году означает автоматическое тестирование каждой новой сборки на предпродакшене для всех приложений, которые имеют высокую бизнес-ценность, обрабатывают чувствительные данные или быстро меняются.

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

Предпродакшен полностью меняет уравнение. На стейджинге или в CI/CD нет риска вывести из строя продакшен-сервис или повредить живые данные, поэтому можно тестировать то, что действительно важно: внедрение кода, нарушенный контроль доступа, IDOR, BOLA/BFLA.

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

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

Раньше для использования DAST требовалось, чтобы инженер по безопасности вручную исследовал приложение, находил все конечные точки, настраивал аутентификацию, создавал профили сканирования — недели работы до самого первого запуска проверки. Именно это годами тормозило внедрение DAST. Искусственный интеллект кардинально меняет ситуацию. Мы используем ИИ для автоматического обнаружения новой атакуемой поверхности из исходного кода и автонастройки конфигурации тестов. То, что раньше занимало недели ручной настройки, теперь требует часов. Это не просто улучшение отчётности. Это устранение главной причины, по которой команды выбирали SAST — его было проще включить.

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

Я бы немного переформулировал вопрос. Команды AppSec ищут не просто улучшенный инструмент (например, для лучшего поиска уязвимостей). Они ищут решения, которые масштабируются, устраняют информационный шум и дают реальное понимание рисков. Развитие с помощью ИИ делает все эти три аспекта критически важными.

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

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

В StackHawk мы используем искусственный интеллект для анализа спецификации API, чтобы понять, как он задумывался к использованию, выявить взаимосвязи между конечными точками, определить контекстное значение параметров и установить необходимые границы авторизации. Это позволяет нам перейти от общего фаззинга к тестированию, осведомлённому о бизнес-логике, при каждом сканировании. Вместо простого вопроса «можно ли здесь внедрить SQL?» мы задаёмся вопросом: «можно ли манипулировать этим идентификатором заказа, чтобы получить доступ к истории покупок другого пользователя?» Это принципиально другой класс находок, и он возможен только тогда, когда ИИ применяется для обнаружения, а не только для составления отчётов.

Мы не наблюдаем убедительных доказательств того, что ИИ коренным образом меняет структуру программного обеспечения; более того, есть аргумент, что он становится лучше в избегании распространённых небезопасных паттернов. Более значимый сдвиг — это скорость и контекст разработчика. Разработчик, использующий ИИ-ассистента, может создать полноценный API с аутентификацией и авторизацией за считанные минуты, проверяя его на предмет «работает ли это так, как я хочу?», а не «не открыл ли я только что административную конечную точку без надлежащего ограничения ролей?» Код не становится странным. Его просто становится больше, он создаётся быстрее, и за каждым решением стоит меньше контекста разработчика.

Что ИИ не может воспроизвести, так это бизнес-контекст: кто, при каких условиях и к чему должен иметь доступ. Именно здесь кроется риск, и он виден только во время выполнения. Статический анализ показывает, как выглядит код. Динамический анализ безопасности приложений (DAST) показывает, что он делает. StackHawk объединяет обнаружение на уровне кода с проверкой во время выполнения, чтобы успевать за скоростью разработки, автоматически находя новые конечные точки по мере их появления в коде и тестируя их в CI/CD до попадания в продакшен. Риск не в том, что ИИ пишет код, который ваш сканер не может понять. Риск в том, что ИИ пишет больше кода, чем ваша команда безопасности может проверить, и без автоматизированного тестирования во время выполнения эти пробелы попадают в продакшен непроверенными.

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

Лучший подход — это тестирование в предпродакшенных средах, таких как стейджинг, QA и CI/CD, где ваше приложение работает на том же коде и с той же конфигурацией, что и в продакшене, но вы не затрагиваете реальные данные или живых пользователей. Вы получаете ценность DAST, проверяя эксплуатируемость, валидируя бизнес-логику и подтверждая контроль доступа в среде с нулевым риском для производственных систем.

Опасение "мы не можем инструментировать продакшен" часто является наследием устаревших DAST-инструментов, которым для эффективности требовались среды, похожие на боевые, или средств защиты времени выполнения, таких как RASP, которые буквально встраиваются в ваш продакшен-стек. DAST с искусственным интеллектом работает иначе. Вы тестируете запущенное приложение, но делаете это до продакшена, в вашем конвейере, на каждом пул-реквесте, как часть рабочего процесса разработки. Именно там вы и хотите обнаруживать подобные проблемы. Найти сломанный контроль доступа в продакшене означает, что уязвимость уже можно эксплуатировать. Обнаружить его в CI/CD означает, что она никогда не попадёт в релиз.