Restructure vulnerability report's Tool filter

Why are we doing this work

The current list of options in the Vulnerability Report (example) 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 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" as the "analyzer" is a legacy behaviour utilised by most GitLab analyzers.

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 for now.

Proposal

Make the following changes to the Tool menu:

1. Use report_type instead of the scanner vendor as the "heading"
2. Show the scanner name under the report type
3. 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
• Scanner filter behaving erratically on Group Vulnerability Report

Excerpt for standalone vulnerability page:

• Analyzer description in the security report schema
• Scanner description in the security report schema

Non-functional requirements

• 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

• 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.

/cc @dftian @matt_wilson @lkerr @sam.white @andyvolpe