[go: up one dir, main page]
Skip to content

Update MR widget to consider sbom based security findings

Why are we doing this work

With the deprecation of Gemnasium, there is a need for displaying sbom-based security findings by the MR Widget.

Relevant links

Non-functional requirements

  • Documentation:
  • Feature flag:
  • Performance:
  • Testing:

Potential solution

Instead of fetching sbom data as in-memory sbom reports (i.e., above solution), sbom related security findings could be be fetched as part of the findings_finder, which implies that Security::Finding would be persisted. Therefore, the ingestion might require changes around store_grouped_scans_service and store_scans_service in order to have sbom report data ingested. Another possible approach is to have the sbom data loaded as security report and reuse the whole of the ingestion flow as is.

This approach aligns with the requirements for both Add support for security findings into pipeline... (#490334 - closed) • Zamir Martins • 17.9 • Needs attention and Add support for merge request approval policy (#490347 - closed) • Oscar Tovar • Backlog. With security findings persisted a new comparison service will be required as it will differ from the existing logic (used by other report types).

Alternative solution based on this POC MR

  • backend Update MergeRequest#enabled_reports and add something like new_cyclonedx_comparison_path to window.gl.mrWidgetData so the frontend code can consider sending request to -/merge_requests/:id/security_reports?type=cyclonedx. This is going to require adding cyclonedx as part into ULTIMATE_FEATURES and REPORT_LICENSED_FEATURES.
  • frontend Update MergeRequestStore.setPath with the new path, e.g. new_cyclonedx_comparison_path and updated the list of endpoints in WidgetSecurityReports to include the new path in relation to CYCLONEDX. This will initiate the request to security_reports with type set to cyclonedx.
  • backend Update MergeRequestSecurityReportGenerationService by adding cyclonedx into ALLOWED_REPORT_TYPES and reports.
  • backend Create a new method into MergeRequest in order to trigger compare_reports in case there are sbom reports.
  • backend Add create_at into Sbom::Report so it can be provided by the report artifact in EE::Ci::Build#collect_sbom_reports!.
  • backend Update Security::PipelineVulnerabilitiesFinder#requested_reports so it can also consider cyclonedx data with findings via VulnerabilityScanning::SecurityReportBuilder.
  • backend Update VulnerabilityScanning::SecurityReportBuilder so it can traverse the valid sbom reports and return their respective security report with findings. Similar to what has been done for Sbom::CreateVulnerabilitiesService.

Note: This alternative solution would only work if there the scope of this epic was only in regards to MR widget. The fact that it includes MR security report and approval rules seems to invalidate this approach.

Verification steps

Edited by Zamir Martins