### Problem The output from DAST is a debugging log that is not readable or useful for end users to see. This increases the cognitive load on users and makes it harder for users to self-diagnose scans. It's also a burden on support who have to dig through log files to understand what DAST is doing. ## 📄 Proposal (Updated) The current DAST job output is verbose, diagnostic-focused, and difficult for end users to interpret. Our goal is to replace this with a **concise, human-readable console output** summarizing key scan phases and results — optimized for clarity, usefulness, and self-diagnosis. This will be implemented over **three structured phases**, with a **feature flag** to revert back to the diagnostic output if needed, allowing for safe rollout and iterative development. --- ## ✅ Phase 1 – MVC Issue link: https://gitlab.com/gitlab-org/gitlab/-/issues/553625+s ### Override the feature With the MVC release, the job console will display a concise summary of DAST activity by default (see [MVC issue](https://gitlab.com/gitlab-org/gitlab/-/issues/553625) for details). To display the full diagnostic log in the job console instead, a feature flag is provided until 19.0 `DAST_FF_DIAGNOSTIC_JOB_OUTPUT`: ```yaml dast: variables: DAST_FF_DIAGNOSTIC_JOB_OUTPUT: "true" ``` ## What's next? _**To be updated with [Phase 2 breakdown](https://gitlab.com/gitlab-org/gitlab/-/issues/485852#note_2573557026) in the next milestone**_ > **Note:** This piece of work affects only the job console output (CI/CD job log). The diagnostic log file artifact (`gl-dast-scan.log`) remains unchanged. --- ## Previous proposal ### Proposal Send the current job console output to a log file that is attached to the job, and re-do the output of DAST to be focused on users. The changes will be iterative, with a first iteration goal of providing: 1. Header and analyzer version 1. Overview of configuration 1. What DAST is doing (site validation, crawling, and scanning) 1. A simple summary of what was done at the end All output should have a purpose and be human readable. ### Proposed Implementation Plan 1. Create a new implementation of `Log` called `ScanSummaryLogger`. 1. Use Go's [`slog` package](https://go.dev/blog/slog) as the underlying logger. 2. This implementation will format the output as mentioned in the issue description. 2. It will support the `INFO`, `WARN`, `ERROR` and `FATAL` log levels. 3. (optional) Use ANSI escape codes to add color to the log based on log level: https://gist.github.com/ik5/d8ecde700972d4378d87 and https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797#color-codes 4. `ERROR` and `FATAL` log should always assign the error field in the log event before logging the message. 2. Use the new logger to print relevant information. 3. Use a feature flag to allow extensive testing of this feature. ##### Suggestions for logs The aim is to convey limited yet meaningful information about how the scan is progressing. 1. DAST Version 2. Chromium Version 3. DAST CWE checks version (if available) 4. Target site validation (beginning and success/failure) 5. Authentication (beginning and success/failure) 6. Crawling progress (beginning, progress, and success/failure) 1. Progress message: "Visited x paths, y URLs" 2. Success message: "Crawl completed in \<duration\>" 3. Failure message: "Failed to crawl the target" 7. Active scan progress (beginning, progress and success/failure) 1. Success/failure messages similar to the crawling progress 2. Progress message: "Executed x% attacks" 8. Passive scan progress 9. Any other relevant logs that the customer could find useful. Inspiration for styling and content: https://gitlab.com/gitlab-org/gitlab/-/issues/485852#note_2196759411