[Design] On-demand DAST Configuration Parity

Problem

Today, On-demand DAST scan configuration is very limited and includes:

• Site profile (name, type, target URL, excluded URLs, request headers, authentication, scan method)
• Scanner profile (profile name, scan mode, crawl timeout, target timeout, debug messages)
• Scan schedule

Pipeline-based DAST scans include many, many more variables/configuration settings. Without the ability to select these settings, On-demand DAST scans may completely fail, meaning customers can't use on-demand scans and must use pipeline-based scans.

Recently, this had led to at least 4 RFH issues where prospects were unable to successfully trial On-Demand scans.

Scope

Must-have

• Ability to fully configure on-demand scans with all variables that can be configured for pipeline-based DAST scans
• Configuration settings can be saved and reused for multiple DAST scans
• Any change made to the configuration should result in an audit event
  • Config variable added, edited, or deleted

Proposal

For MVC, expose a box on the on-demand configuration page that allows customers to directly edit YAML, so they can leverage all DAST configuration variables for on-demand scans.