Skip to content

Dependency Scanning loading resulted in an error within MR widget

Summary

If your pipeline contains Dependency Scanning artifacts from both the base gemnasium dependency scanning job as well as the gemnasium-python dependency scanning job, the Security scanning widget in the merge request will display Dependency scanning: Loading resulted in an error.

Using the browsers network debugger, we can see requests to the dependency_scanning_reports.json file for the MR (e.g. https://gitlab.com/group/project/-/merge_requests/1/dependency_scanning_reports) is returning a 400, with a status_reason of JSON parsing failed.

The results of these scans still appear without issue in the full report, and on the Security tab of the pipeline itself. The reports themselves are valid as well.

Steps to reproduce

Example Project

What is the current bug behavior?

The Dependency Scanning section of the Security scanning MR widget displays Dependency scanning: Loading resulted in an error.

What is the expected correct behavior?

The widget properly displays the scanners findings of both valid reports.

Possible fixes

The problem happens when merging artifacts into one report (and it's called here). Findings are compared by scanner keys and in the case of this issue, this comparison fails as one of the reports (python one) returns nil instead of an array of keys.

For undiscovered reasons when scanners are compared, in some cases vendor is returned as nil. As we're going to remove scanner category from vulnerabilities, see #233359, it makes sense to make a small fix for now.

Failing examples:

> a = [3, "gemnasium", "Gemnasium", nil]
> b = [3, "gemnasium", "Gemnasium", "GitLab"]
> a <=> b
=> nil

Comparing with compact fixes this issue.

Proposed fix

Update scanner comparer to compare compact arrays of keys.

Edited by Tetiana Chupryna