Split SAST, Dependency Scanning reports
Summary
SAST reports and Dependency Scanning (DS) reports share the same syntax defined in the common/issue Go package. As SAST and DS evolve, the reports get more refined and it's becoming harder to share the same codebase to generate them. We need to split what's currently in common/issue, in a way or another.
Proposal
Two ways we can split:
- share a common
VulnerabilityGo struct and embed to define DS and SAST vulnerability structs - split the source code and ensure consistency across different kinds of reports by defining a shared JSON schema
Improvements
No side-effect in SAST reports when introducing new fields related to DS. This would solve https://gitlab.com/gitlab-org/gitlab-ee/issues/9332 and avoid discussions about possible side-effects when introducing new fields, like gitlab-org/security-products/analyzers/common!35 (diffs, comment 173778070).
We could leverage this refactoring to rename the Issue Go struct to Vulnerability, see https://gitlab.com/gitlab-org/gitlab-ee/issues/8398.
Blockers
Right now the split would be challenging because the orchestrator package (both DS and SAST rely on) instanciate a issue.Report and call Report.Merge. It would be a lot easier to split after removing the orchestrator, which is covered by these two issues:
- Move reports logic for security reports to backend https://gitlab.com/gitlab-org/gitlab-ee/issues/8519
- Support uploading of multiple security reports of the same category https://gitlab.com/gitlab-org/gitlab-ee/issues/10857
Involved components
- https://gitlab.com/gitlab-org/security-products/analyzers/common
- reverse dependencies of common: SAST, DS and their analyzers