Support uploading of multiple security reports of the same category
Problem to solve
We currently only support the upload of a single ~Secure report within a pipeline. If multiple jobs attempt to upload a report (e.g. gl-sast-report.json
), such as in the case where analyzers are used directly for multiple languages, all will be uploaded. However there are limitations that prevents working with these reports correctly:
- For the Group level dashboard, the reports are parsed and then given to the DB storage algorithm which is not meant to be used with multiple reports and might produce unexpected behavior.
- For Project level Dashboard, MR widget and pipeline view, only one report will be returned.
This prevents us from splitting scans across multiple jobs and correctly handling multiple reports of the same type.
Intended users
Further details
In order to support workflows such as analyzer-level sast
templates we must first support parsing and display of multiple reports. The current logic grabs the first one and assumes there will never be multiple, so others will simply be ignored.
Proposal
This is a backend only task and involves refactoring the ruby within the gitlab-ee
application to both expect and parse multiple reports incoming from a pipeline.
The goal is to allow all uploaded reports to be parsed, which will allow us to split out our security scans and give us more flexibility.
Permissions and Security
No change in permissions
Documentation
What does success look like, and how can we measure that?
Customers can run multiple security scanning jobs of the same category (e.g., multiple SAST jobs) within a pipeline and all reports will render within MR widget and dashboards.
What is the type of buyer?
Links / references
Development Log
Status (High level goals)
-
Update rails app to parse all uploaded security reports (instead of just the first) Status note: I'm still debugging some problems in unit tests for this part -
Agree on formatting of "CWE" externlal_type
value inGitlab::Ci::Reports::Security::Identifier
, see the discussion
-
-
Port deduping logic from common to rails app -
Port sorting logic from common to rails app
Decisions
-
no need for an explicit Rails app update to parse all uploaded security reports (instead of just the first) as it's already being done: every report artifact blob of a certain type (e.g.This was a false assumption which was correct by this explanationsast
) is collected (proof 1, proof 2) however, I'm leavingUpdate rails app to parse all uploaded security reports (instead of just the first)
unchecked for now since deduping and sorting implementation are not settled down and changes into parsing code may be required- there was no need of porting the sort for dependency files since dependency list reports are managed separately
- the test fixtures for SAST in GitLab EE are updated to have primary identifiers for all of the occurrences; we have acknowledged again that CWE-only occurrences to cause duplicates since there's no sense of treating CWEs as actual identifiers
- currently, the occurrences de-duplication algorithm excludes CWE identifiers in a case-insensitive manner - to support both current DAST parser format (
CWE
) andcommon
library format (cwe
).