<!-- Implementation issues are used break-up a large piece of work into small, discrete tasks that can move independently through the build workflow steps. They're typically used to populate a Feature Epic. Once created, an implementation issue is usually refined in order to populate and review the implementation plan and weight. Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan --> ## Why are we doing this work The current list of options in the Vulnerability Report ([example](https://gitlab.com/thiagocsf-group/demo/container-scanning-test-2/-/security/vulnerability_report)) has a hard-coded list of GitLab report types on the top, a horizontal line, and a dynamic list of "custom" scanners. For example, the `Aquasecurity/Container Scanning` option below is dynamically inserted because a security report with these values was ingested by the project.  The [VulnerabilityScanner](https://docs.gitlab.com/ee/api/graphql/reference/index.html#fields-705) GraphQL query used to build the dynamic list has a `vendor` field, which is expectedly populated from `scan.scanner.vendor`. However, `scanner.vendor` is supposed to represent the scanner tool, not the analyzer integration. The latter has a dedicated `scan.analyzer.vendor` field for this purpose. It seems that using "[scanner](https://docs.gitlab.com/ee/user/application_security/terminology/#scanner)" as the "[analyzer](https://docs.gitlab.com/ee/user/application_security/terminology/#analyzer)" is a [legacy behaviour utilised by most GitLab analyzers](https://gitlab.com/gitlab-org/gitlab/-/issues/340689#note_677087082). As a result of this inconsistency, a recent change in container-scanning "fixed" the vendor for Trivy to be Aquasec instead of GitLab. This had the unintended consequence of altering the Tool filter. [The change was reverted](https://gitlab.com/gitlab-org/security-products/analyzers/container-scanning/-/merge_requests/2591) for now. <!-- A brief explanation of the why, not the what or how. Assume the reader doesn't know the background and won't have time to dig-up information from comment threads. --> ## Proposal Make the following changes to the Tool menu: 1. Use `report_type` instead of the scanner vendor as the "heading" 1. Show the scanner name under the report type 1. Show the analyzer vendor next to the scanner name Add the following fields to the (standalone) vulnerability page: - Analyzer name, Analyzer vendor, Analyzer version - Scanner name, Scanner vendor, Scanner version ### Current menu - **GitLab** - Container Scanning - Cluster Image Scanning - DAST - Dependency Scanning - etc - **Anchore** - Container Scanning - **Aquasecurity** - Container Scanning ### Proposed menu - **Container Scanning** - Trivy (GitLab) - Trivy (Aquasecurity) - Grype (GitLab) - Grype (Anchore) - **Cluster Image Scanning** - **DAST** - Browserker (GitLab) - Zap (GitLab) - **Dependency Scanning** The following functionality remains unchanged: - Selecting the heading (e.g. "DAST") selects all scanners under it. - Scanners only show under the heading if there are results for them. For the Container Scanning example, "Trivy (Aquasecurity)" and "Grype (Anchore)" would only show if someone used a 3rd party integration for these scanners. ## Relevant links These might want to be (re-)considered as part of this work. - [Expand filtering functionality of vulnerabilities GraphQL endpoint to support scanner ID](https://gitlab.com/gitlab-org/gitlab/-/issues/293843) - [Scanner filter behaving erratically on Group Vulnerability Report](https://gitlab.com/gitlab-org/gitlab/-/issues/332727) Excerpt for standalone vulnerability page:  - [Analyzer description in the security report schema](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/161081ffe01069fd57c38345aec81f7ac912565d/src/security-report-format.json#L32-34) - [Scanner description in the security report schema](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/161081ffe01069fd57c38345aec81f7ac912565d/src/security-report-format.json#L73-75) ## Non-functional requirements <!-- Add details for required items and delete others. --> - [ ] Documentation: - [ ] Feature flag: this change must be done behind a feature flag so it can be tested with production data in a controlled manner. - [ ] Performance: - [ ] Testing: ## Implementation plan - [ ] Scoped to Project level vulnerability report page for MVC - [ ] Create feature flag so that we can test this on production before rolling it out live for all users. - [ ] Modify `ee/app/assets/javascripts/security_dashboard/components/shared/filters/scanner_filter.vue` to show `report type -> scanner` instead of `vendor -> report type` like what it currently does. - [ ] Modify the relevant GraphQL queries to filter by `scanner` instead of `scannerId`. - [ ] Use `scanner_filter.vue` on the group and instance level reports. It's currently only used on the project level report.