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 Vulnerability Go 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

/cc @gonzoyumo @twoodham @theoretick @plafoucriere

Edited May 29, 2019 by Fabien Catteau
Assignee Loading
Time tracking Loading