UX Audit: API fuzzing configuration UI

⚡️ Summary

As part of Secure: Scan Configuration Evaluation, we are performing an audit of the states and UI patterns for every security scanner with a configuration interface. The goal of the audit is to identify patterns and inconsistencies and create recommendations focused on improving consistency and learnability between the scanners. This issue is to track and document findings for API Fuzzing configuration.

The parent issue that documents all scanners being audited is linked below:
👉 #340334 (closed)

📋 Plan

• Identify relevant JTBD
• Evaluate the configuration process and document existing workflows (user flows)
• Capture screenshots of the configuration interface including all possible states
• Review any new or upcoming configuration changes for SAST and note anything that deviates from the audit findings and/or adjust findings accordingly
• Document findings in an easy to digest way

💼 JTBD

1. When I am configuring a CI/CD security scan, I want to specify which assets need to be scanned and under which circumstances, So that I can ensure my assets are secure prior to or at their release.
2. When I am configuring a security scan, I want to specify which types of vulnerabilities the scan should detect, So that we don't waste time sorting through irrelevant findings.
3. When I am either enabling or configuring a security scan, I want to run a demo scan, So that I can validate my configuration before it is implemented

📷 Screenshots

See design section below

🚶 Workflow

🎨 FigJam File

📄 Relevant issues

1. project level configure: edit bearer token (add bearer token auth to ui) ← suggests a redesign the configuration page
2. Profiles (reusable scan profiles)
   1. Project-level: configure with local(project) profile
   2. Project level: configure edit route
   3. Project level: manage profiles
   4. Project level: configure with group profile
   5. Group level: manage group profile
3. On-demand/continuous fuzzing (epic)

💡 Findings

Does the API Fuzzing configuration UI address the JTBD(s)?

0 of 3 JTBD can be addressed using the DAST CI/CD configuration UI

1. 𐄂 JTBD 1 is not addressed by the configuration UI; users can only provide a base URL at this time. This will be addressed by the addition of custom "profiles" (see relevant issues below).
2. 𐄂 JTBD 2 is not addressed by the configuration UI; users can only select a predefined profile at this time. This will be addressed by the addition of custom "profiles" (see relevant issues below).
3. 𐄂 JTBD 3 is not addressed within the API Fuzzing configuration flow. There is no way to run a "demo" scan to validate the configuration from the UI.

Findings unique to API Fuzzing

1. There is no warning or way to indicate if API Fuzzing is properly configured other than reviewing a specific pipeline instance. An erroneous configuration will still display API Fuzzing as Enabled (Note: This has not yet been verified as a problem unique to API fuzzing)

Findings shared with other scanners

1. Field validation is minimal or non-existent
   1. There is no form field validation within the API Fuzzing configuration UI. All fields accept any value.
2. Configuration values are not maintained when returning to the config page (DAST does not maintain values either)
3. Unlike other scanners, the DAST CI/CD and API Fuzzing UIs both direct users to commit changes directly to the .gitlab-ci.yml file instead of creating a merge request. The process of creating a merge request is a separate, deliberate action users must take.
4. The end of the configuration process (merging code to enable the feature) doesn't do a great job assuring users that the scanner is properly enabled
   1. When API Fuzzing is successfully enabled, the only place to confirm this is on the pipeline details page or within the Security & Compliance menu. The change in system status is not easily discovered.
5. Not all configuration options are exposed in the UI