Remove issue.Scanner and issue.Category from analyzer projects

Problem to solve

Now that Output scan object in report has been completed and the common package has access to the Scanner and ScanType fields passed to the Config struct by the analyzer, we no longer need to explicitly pass the scannerinfo.IssueScanner or issue.Category when creating an issue. The common library can extract the Issue.Scanner.ID and Issue.Scanner.Name fields from the Scanner Config option and the issue.Category from the ScanType Config option.

Intended users

Proposal

  1. Add code to the convert function to loop through all issues created by the scanner and automatically insert a populated issue.Scanner struct with values from the cfg.Scanner struct, and also set the correct vulnerability.Category value:

    report, err := cfg.Convert(reader, c.String(flagPrependPath))
report.Scan.Scanner = cfg.Scanner
report.Scan.Type = cfg.ScanType

for _, vulnerability := range report.Vulnerabilities {
	vulnerability.Category = cfg.ScanType
	vulnerability.Scanner = issue.Scanner{
		ID:   cfg.Scanner.ID,
		Name: cfg.Scanner.Name,
	}
}

  2. Remove the Scanner field when creating an issue from all projects that rely on the common library

  3. Implement the logic described in step 1. for all projects that don't depend on common/command

Further details

This change would remove complexity from the analyzer projects, and also prepare the projects for the day when this Issue.Scanner is removed

What does success look like, and how can we measure that?

issue.Scanner can be removed from the analyzer projects and the reports are still created as expected and pass all existing integration tests.

What is the type of buyer?

Enterprise Edition GitLab Ultimate

Is this a cross-stage feature?

Yes, this will affect all Go-based Secure projects

Links / references

gitlab-org/security-products/analyzers/bundler-audit!45 (diffs, comment 387220487)

/cc @NicoleSchwartz @gonzoyumo @fcatteau

Edited by Fabien Catteau