Skip to content

Concise job console output MVC

Background

Original MVC discussion in the epic: &18342 (comment 2602052071)

Expected outcome mockup :

┌─────────────────────────────────────────────────────────────────┐
│ GitLab DAST │
│ Dynamic Security Testing │
└─────────────────────────────────────────────────────────────────┘

🔍 DAST Scanner v5.6.0 | 🌐 Chrome v133.0.6890.0 |📍 Target: https://example.com/ 

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔐 Authentication Started

⚡ Attempting login to https://example.com/login/ 
Using user-defined selectors to find username/password/submit button 
✅ Authentication successful! Session established.

📊 Progress: • Navigations: 6/12 • Active attacks: 6
📊 Progress: • Navigations: 8/12 • Active attacks: 8 

┌──────────────────────────────────────────────────────────────────┐
│ Scan Summary │
└──────────────────────────────────────────────────────────────────┘

 • Successfully scanned: 2 navigations
 • Skipped: 0 navigations
 • Failed to finish processing: 0 navigations
 • Failed to visit: 0 navigations
 • Vulnerabilities found: 1

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📚 Full report available at: gl-dast-report.json
🔗 Troubleshooting guide: https://docs.gitlab.com/user/application_security/dast/browser/troubleshooting

On auth/scan failure the logs will print out :

┌─────────────────────────────────────────────────────────────────┐
│ GitLab DAST │
│ Dynamic Security Testing │
└─────────────────────────────────────────────────────────────────┘

🔍 DAST Scanner v5.6.0 | 🌐 Chrome v133.0.6890.0 |📍 Target: https://example.com/ 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

🔐 Authentication Started

⚡ Attempting login to https://example.com/login/ 
Using user-defined selectors to find username/password/submit button 
❌ Authentication unsuccessful!

💡 Want more details? 
Set `SECURE_LOG_LEVEL: "debug"` to enable verbose authentication logging:


┌──────────────────────────────────────────────────────────────────┐
│ Scan Failure Summary │
└──────────────────────────────────────────────────────────────────┘

⚠️ Failure Report:
 • Error: authentication failed: failed to authenticate user

💡 Tip:
 To get more debug information, try adding the following config to your CI job:
 `SECURE_LOG_LEVEL: "debug"`

🚨 IMPORTANT:
 Please attach the complete job artifacts ZIP if opening a support ticket with GitLab.
 Artifacts contain logs needed to diagnose issues.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📚 Full report available at: `gl-dast-report.json`
🔗 Troubleshooting guide: https://docs.gitlab.com/ee/user/application_security/dast/browser/troubleshooting

Section Breakdown

Environment & Target Info

Purpose:
Summarizes the scan environment. Shows the DAST scanner version, browser engine, and the target/auth URLs. This helps with reproducibility and debugging by providing clear scan context right up front.

🔐 Authentication Block

Purpose:
Indicates whether authentication was successful, which can be a pain point for our users. This helps users verify their credentials and selectors are working as expected.

For deeper debugging, users can set:

SECURE_LOG_LEVEL: "debug"

📊 Progress Summary

Purpose:
Gives live feedback on how the scan is progressing over a set time. Helps users see real-time activity and gauge how far along the scanner is. It's especially helpful in longer scans to indicate that the scan hasn't stalled.

The data for the progress summary is as follows:

  • Navigations: number of successful + failed navigations / total navigations found
  • Active attacks: number of attacks performed on the site - this will be a large number as this will count every single attack performed

Initially I propose to set this to every 1 minute.

🧾 Scan Summary

Purpose:
A clear wrap-up of what the scan accomplished. Includes the number of pages scanned, skipped, or partially scanned, helpful for coverage analysis and reviewing the count of navigations preformed during the scan. this section also contains the number of vulnerabilities found during the scan.

Footer

Purpose:
Offers follow-up resources. Includes documentation links for troubleshooting.
I think we can also add the link to the configuration page.

🚨 Support Instructions

Purpose:
This section tells users exactly what to do if they’re escalating the issue with support: grab all job artifacts. Without this info, the development team can't help effectively.

❌ Failure Section

Purpose:
When the scan fails, this section explains what went wrong in plain terms. Whether it's a login issue, selector mismatch, or something else—it gets logged here. My thoughts are that we need to be very selective on what "errors" get presented in the Failure Report so that this output doesn't become a second hard to read log output. I'm still on the fence on whether to selectively report errors in a list or remove the section all together and only inform the user that the scan failed, and to please see the verbose log.

for the MVC, we will have the errors output how they are currently formatted when we do select a meaningful error to output, this is in the interest of minimising scope of what's in the MVC, my thoughts are that rewording the errors for this output can be improved on in phase 2 or 3. Not all errors will be outputted and we look to output the most critical ones for the MVC these will be auth errors, failed to start errors, and fail to scan errors. (To be updated after team sync)

Proposal

Implement core scan summary logic using ScanSummaryObserver. The observer captures key metadata and replaces diagnostic logging output by default.

🛠️ 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)

📊 Progress Summary Output

  • Output status updates every 1 minute
  • Output • Navigations: 6/12 • Active attacks: 6 during the scan

🧪 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)

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

Override the feature

By default, the job console displays a concise summary of DAST activity detailed in this MVC. To output the full diagnostic log to the job console enable DAST_FF_DIAGNOSTIC_JOB_OUTPUT:

dast:
 variables:
 DAST_FF_DIAGNOSTIC_JOB_OUTPUT: "true"
Edited by Hannah Baker