Human readable job console output

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 report summarizing key scan phases and results — optimized for clarity, usefulness, and self-diagnosis.

This will be implemented over three structured phases, behind a feature flag to allow for safe rollout and iterative development.

✅ Phase 1 – Core Implementation Checklist (Behind Feature Flag – MVP)

Implement core scan summary logic using ScanSummaryObserver. When the feature flag is enabled, the observer captures key metadata and replaces default logging output.

🛠️ Setup

  • Add a new ScanSummaryObserver to gather data and ScanSummaryReport for managing the output stying
  • Gate output behind a feature flag
  • Suppress standard logging when feature flag is enabled
  • The Coverage Report section as mocked further down

📍 Metadata Collection

  • Record Authentication URL and Target URL
  • Capture success/failure to connect to target
  • Record Authentication section metadata (e.g. login success)

⏱️ Duration Reporting

  • Capture crawl duration
  • Capture active scan duration

📊 Progress Summary Output

  • Output "Visited X paths, Y URLs"
  • Output "Found X findings/vulnerabilities"

🧪 Testing

  • Verify output is generated only when feature flag is enabled
  • Confirm all metadata and durations for phase 1 appear in output
  • Confirm observer output replaces default logs cleanly
  • A dedicated e2e test for the log output should be added, this should model the new format (similar to the auth tests)

🧩 Stretch (Optional if time permits)

  • Minimal success/failure list of URLs
  • Basic vulnerability findings summary (counts or brief list)

To be updated with Phase 2 breakdown in the next milestone

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
  2. Overview of configuration
  3. What DAST is doing (site validation, crawling, and scanning)
  4. 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 as the underlying logger.
    2. This implementation will format the output as mentioned in the issue description.
    3. It will support the INFO, WARN, ERROR and FATAL log levels.
    4. (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
    5. 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: #485852 (comment 2196759411)

Edited by Hannah Baker