MR widget loads indefinitely when pipeline contains an SBoM without dependency scanning attributes

Summary

When the pipeline contains an SBoM that does not have dependency scanning attributes in it, the MR security widget remains stuck in a loading state indefinitely.

First reported in: https://gitlab.com/gitlab-com/request-for-help/-/issues/3359

Steps to reproduce

1. Create a project
2. Add the container scanning CI job template
3. Create and push an example container image to your container registry
4. Make some change to the project and create an MR
5. Allow pipeline to run
6. Notice how the security scan results widget loads endlessly
7. Adapt the container scanning job to only publish the gl-container-scanning-report.json and exclude the SBOM
8. Notice how the security scan results widget now displays correctly

Example Project

What is the current bug behavior?

The MR security results widget loads endlessly.

What is the expected correct behavior?

The MR security widget should show results once reports are done processing.

Cause

The issue may be caused by this change: !186603 (merged)

1. The widget expects there to be dependency_scanning results if there is a cyclonedx artifact and begins polling.
2. We have a redis optimization implemented in !151358 (merged) to reduce the amount of database queries executed when polling. It causes report status to always return :parsing until ::Ci::CompareSecurityReportsService.set_security_report_type_to_ready is called. This is only called when executing StoreGroupedScansService.
3. Sbom-based dependency scanning goes through this code path. StoreGroupedSbomScansService inherits from StoreGroupedScansService, so it does execute this method. However, the problem arises from the file_type which is set here as the key artifact.security_report.type.to_s. If artifact.security_report returns nil or if artifact.security_report.type is container_scanning, then the dependency_scanning reports are never marked as ready.

Possible Fixes

We encountered a very similar issue in !199629 (merged) which was solved with the remove_dangling_dependency_scans method. We can solve this one the same way:

diff --git a/ee/app/services/security/store_scans_service.rb b/ee/app/services/security/store_scans_service.rb
index dff348c4d9f4..11ba5e37eb66 100644
--- a/ee/app/services/security/store_scans_service.rb
+++ b/ee/app/services/security/store_scans_service.rb
@@ -28,6 +28,12 @@ def execute
         end
 
         remove_dangling_dependency_scans
+        # If no dependency scanning reports were processed in `StoreGroupedSbomScansService`, we need to set this
+        # to ready so that dependency_scanning reports do not keep polling.
+        ::Ci::CompareSecurityReportsService.set_security_report_type_to_ready(
+          pipeline_id: pipeline.id,
+          report_type:'dependency_scanning'
+        )
       end
 
       sync_findings_to_approval_rules unless pipeline.default_branch?

Workaround

Adding an empty gl-dependency-scanning-report.json to the pipeline should cause the widget to load.

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.