## Details The Security Dashboards are based on the latest successful pipeline in the Default Branch. There are some cases when results can be incomplete in the dashboard, because one of the security jobs failed in this pipeline. Yet, as jobs are allowed to fail, the pipeline is still considered as successful. ### Problem to solve Users can't see easily if some data are missing from the dashboard because a job failed. #### Problem statements - How might we communicate the state of the vulnerability report [security dashboard] to users? - How might we communicate the report is incomplete or missing data from a defective scan(s). - How might we communicate the report is not current and should be updated? #### Jobs to be done ``` Location: Project > Security Dashboard > Vulnerability List Experience: Reviewing and prioritizing vulnerabilities ``` [+ Primary - scoped to the core experience +] **When** I am managing vulnerabilities for my organization, **I want** to address all serious and time-sensitive threats first, **so I can** ensure my company is not at risk of an imminent attack or breach. `Secondary - scoped to the problem` **When** I am preparing to triage vulnerabilities, **I want to** know if my report is current and includes the results from all of my enabled scanners, **so I can** feel confident I am viewing all detectable vulnerabilities in my project. *Tertiary - scoped to the problem/solution* **When** my report is not current or missing data, **I want to** identify the problem and begin the process of addressing it, **So I can** be assured I am prioritizing and triaging all detectable vulnerabilities in my project. #### Intended users * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ## Solution space & Scope >How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey 1. Users should be able to identify if there is a problem with the state of their report 2. Users should be able to determine the cause of the problem if their report is inaccurate or incomplete ### Proposal * Add description under page title: > The Security Dashboard shows the results of the last successful pipeline run on the default branch. * Add pipeline widget with `Last updated` copy, how long ago the most recent pipeline passed, and a pipeline number which links to the pipeline page * Show failed job(s) badge, if any, which links to the failed jobs page of the pipeline If jobs all passed successfully, no badge appears:  If job(s) failed, show badge with count of failures. Badge links directly to `Failed jobs` tab of pipeline page:  ___ ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> Nothing new. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> Update https://docs.gitlab.com/ee/user/application_security/security_dashboard/ accordingly. ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> Have a pipeline with a failing job, check that we report it in the dashboard. ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> Less users confused ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ~"GitLab Ultimate" ### Links / references