UX Audit: DAST CI/CD 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 DAST CI/CD configuration.
The parent issue that documents all scanners being audited is linked below:
📋 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 DAST CI/CD and note anything that deviates from the audit findings and/or adjust findings accordingly -
Document findings in an easy to digest way
💼 JTBD
- 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.
- 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.
- 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
📄 Relevant issues
- Show better error descriptions
- Authenticate before running full DAST scan
- Profiles
-
"Multi-page" option to Site profile authentication (design complete, implementation planned)
👈 notable design changes - "Submit button identifier" option to the Site profile authentication(design complete, implementation planned)
- DAST Site profile: Header addition redesign (design complete)
- Reorganize scanner & site profile library (design proposed)
- Allow user to validate site profile from
New on-demand DAST scan
page - Filter scanner/site profiles
- Restrict specific profile features to certain access levels
- Add additional customization options for scanner and site profiles
-
"Multi-page" option to Site profile authentication (design complete, implementation planned)
💡 Findings
Does the DAST CI/CD configuration UI address the JTBD?
1 of 3 JTBD can be addressed using the DAST CI/CD configuration UI
-
✓
JTBD 1 is addressed with DASTSite profiles
-
𐄂
JTBD 2 is partly addressed with DASTScanner profiles
, but doesn't provide users with much granularity. Users can only choose between anactive
orpassive
scan. Currently, DAST rules must be configured using CI/CD variables within the.gitlab-ci.yml
file -
𐄂
JTBD 3 is not directly addressed within the DAST configuration flow. There is no way to run a "demo" scan to validate the configuration from the UI.
Findings unique to DAST (CI/CD + on-demand)
- The configuration process for DAST CI/CD is easily one of the more complicated workflows across all of GitLab's security scanners.
- Requires users to create
Site
andScanner
profiles (separate, but integrated workflows) - To run an "active" scan against a target, the site profile must first be
verified
. (Note: this process isn't explicitly documented in the workflow diagram above but adds to the overall complexity of enabling DAST.)- DAST is the only scanner that requires users to verify ownership of the target
- The complexity of the workflow can vary, depending on the state of a current project
- Configuring DAST for the first time requires a handful of additional steps
- If relevant site and scanner profiles already exist, the process can be quick but is still more involved than other scanners
- Requires users to create
- Unline other scanners, DAST utilizes reusable "Profiles" for UI configuration
- Profiles allow users to make changes to their DAST configuration without having to update their code (changes made to in-use profiles can be applied without updating code)
Findings unique to DAST CI/CD
Findings & themes shared with API fuzzing
- 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. - Unlike most other scanners (fuzzing being the exception), DAST CI/CD requires users to manually create or update the
.gitlab-ci.yml
file.- Users aren't given much help if their project doesn't have a pipeline configuration file already. In this scenario, users must deviate from the process of enabling DAST and enter the workflow to create a pipeline first.
- Both DAST and fuzzing have the concept of profiles. However, fuzzing profiles are premade and very basic at the moment. There are plans to expand fuzzing profiles.
Findings & themes observed across multiple scanners
-
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
- When DAST 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.
- When DAST is successfully enabled, the only place to confirm this is on the pipeline details page or within the
-
Field validation is minimal or non-existing
- The DAST configuration UI has some validation but there are opportunities for improvement
-
Not all configuration options are exposed in the UI