### Problem to solve Problem: Users are finding it difficult to configure security scans and identify which security scans have been activated. Context: In https://gitlab.com/groups/gitlab-org/-/epics/1784 study, only 1 of 5 users were able to properly configure a security scan when given the task. We found that users navigated to the left nav security section with ease; however were disappointed when arriving to this section and not finding a "on/off" switch. ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### Further details * Follow up issue: https://gitlab.com/gitlab-org/gitlab/issues/13646, which will enable the user to configure a security scan directly from UI (validation issue: https://gitlab.com/gitlab-org/ux-research/issues/359 and [study results](https://docs.google.com/presentation/d/1blpG78sBTNYcFyP1DH4gNjmJSB8SGm4xMgVtOe9UXLo/edit?usp=sharing)). * Dependency on https://gitlab.com/gitlab-org/gitlab/merge_requests/17568 completion * As an MVC the configuration status shown relates to the default branch. Future iterations will aim to show where/what branches have security scans configured. ### Proposal Add a configuration section to the Security and Compliance left navigation. This UI will show the user security scans available, what scans have been configured, and provide clear links to the documentation. 1. Introduce a new screen under `Security & Compliance`, called `Configuration` 1. On the new screen, display to users whether each of the various security scans is activated or disabled 1. Link to relevant product documentation on how to manually enable/disable scanning | Info architecture | Default UI | AutoDevOps UI | | ------ | ------ | ------ | |  |  |  | Blue info banner copy is: > The configuration status of the table below only applies to the default branch and is based on the latest pipeline. Once you've configured a scan for the default branch, any subsequent feature branch you create will include the scan. Latest pipeline link: i)if pipeline if there is no pipeline link to https://docs.gitlab.com/ee/ci/pipelines.html, ii) if the pipeline is configured links anchors to project pipeline page. "Configuration" defined as: in the pipeline of the default branch, there's at least one job generating a particular kind of report. This is true as soon as the CI config has been parsed and evaluated, even if the pipeline is still pending. (mentioned by Fabien here: https://gitlab.com/gitlab-org/gitlab/issues/13662#note_215607663) <details> <summary>:notebook: UI copy details</summary> **(Seen in info banner):** > Configuration status only applies to the default branch and is based on the latest pipeline scan. * *latest pipeline* is linked to the project pipeline page **(Seen in info banner, when project configured Auto DevOps):** > All security scans are enabled because Auto DevOps is configured on this project. * *Auto DevOps* is linked to https://docs.gitlab.com/ee/topics/autodevops/ **Static Application Security Testing (SAST)** > Analyze your source code for known vulnerabilities * Documentation icon links to https://docs.gitlab.com/ee/user/application_security/sast/ **Dynamic Application Security Testing (DAST)** > Analyze a review version of your web application * Documentation icon links to https://docs.gitlab.com/ee/user/application_security/dast/ **Container Scanning** > Check your Docker images for known vulnerabilities\ * Documentation icon links to https://docs.gitlab.com/ee/user/application_security/container_scanning/ **License Compliance** > Search your project dependencies for their licenses and apply polcies * https://docs.gitlab.com/ee/user/application_security/license_compliance/ </details> ### Permissions and Security UI is visible to all project participants ### Documentation Add a new `Configuration` sub-section to the (Application Security)[https://docs.gitlab.com/ee/user/application_security/] section of the documentation. Explain the purpose of the new screen and detail how to use each of the components. Ideally, include screenshots to clarify what has been added and for what purpose. Also be sure to highlight the initial limitations of no advanced configuration or disabling of enabled scans from this screen. ### Testing .. ### What does success look like, and how can we measure that? * User navigates to section (when tasked with setting up scans) and better understand how to configure the scans * The documentation links are clear and helps guide users to set up security scans => [Related research study](https://docs.google.com/presentation/d/1blpG78sBTNYcFyP1DH4gNjmJSB8SGm4xMgVtOe9UXLo/edit?usp=sharing) ### What is the type of buyer? ~"GitLab Ultimate" ### Links / references <details> <summary>2nd iteration</summary> | **i.** Information architecture | **ii.** UI (wireframe) configuration | **iii.** Already configured | | ------ | ------ | ------ | |  |  |  | | Configuration accessible in left nav - user testing showed users went to this location to attempt to configure SAST https://gitlab.com/groups/gitlab-org/-/epics/1784 | UI displays info text, Secure features, and configuration status (all anchors seen link to documentation or "latest pipeline" to pipline page) | UI displays in the case that AutoDevOps has been configured | Leverage our documentation by displaying the most relevant configuration next steps and corresponding documentation (links) directly in the UI. Additionally, communicate configuration status/awareness needed for the feature to be activated. feedback: * Use the word "configured" instead of "activated" * Identity another term when not configured: could be "unconfigured", "not configured", or ? * As a follow-up issue, we'd want to communicate to the user if a feature is supported or not. Example, instead of "not yet configured" the status would read "not supported" (languages) </details> <details> <summary>initial iteration</summary> | i) MVC | ii) Dashboard, w/ 1+ scans configured | iii) User one-click configuration | | ------ | ------ | ------ | |  |  |  | | System identifies that the project isn't configured to run security scans. The UI displays an awareness message to user. Links displayed to documentation for configuration requirements | Once 1 or more scans have been set up, visualize the scans that have been enabled in the dashboard. This serves user 1) awareness of what scans are providing data in the dashboard, 2) nudge to utilize other scans. Admin has the ability to remove the section “don’t show me this” (or removed after X days) | Displays configuration documentation links, with ability to add scan configuration script to the project’s `.gitlab-ci.yml` file. Following UI displayed in the configuration concept: https://gitlab.com/gitlab-org/gitlab-ee/issues/13646 | **Video:** [UX group review, ideation, and feedback session](https://www.youtube.com/watch?v=zLLeNAEeU68) Notes: * Issue evolved to focus on configuration page showing configuration status. Will open separate issues to address day 1 UI on the dashboard, dependency list, and compliance list - similar to https://gitlab.com/gitlab-org/gitlab-ee/issues/12685 </details> ### Implementation plan * [ ] ~backend * [ ] ~frontend * [ ] Basic page entry point * [ ] JS entry point * [ ] New sidebar-menu item * [ ] Presentational Vue Component * [ ] Basic Layout / Breakpoints (following current settings pages) * [ ] Notifications * [ ] Features Table * [ ] ~~Vuex Store (TBC)~~ * [ ] ~~Container Component for data fetching~~