Skip to content

Group Vulnerability Report Empty When Group Has No Projects

Summary

When users have security scanning enabled, they can view the results via the Vulnerability Report. The vulnerability report should be accessible via projects, groups, and the Security Center.

However, if a group has no projects, then the group vulnerability report will be empty with the following warning:

Monitor vulnerabilities in your group Manage and track vulnerabilities identified in projects within your group. Vulnerabilities in projects are shown here when security testing is configured.

Workaround:

As a workaround, users can create a test project in their group. After at least one project is created, the vulnerability report should populate the security scanning results identified in projects within subgroups. If all projects are again removed from the group, the issue will resurface.

Steps to reproduce

  1. Create a new Group (vulnerability-report-bug)
  2. Add a subgroup but no projects (vulnerability-report-bug/subgroup-1)
  3. Add a project to the subgroup (vulnerability-report-bug/subgroup-1/secret-detection)
  4. Configure/Run a Security Scan.
  5. Notice that the Vulnerability Report is empty in the vulnerability-report-bug group. However, the results are viewable in both vulnerability-report-bug/subgroup-1 and vulnerability-report-bug/subgroup-1/secret-detection

NOTE: Adding a test project to vulnerability-report-bug will resolve this issue.

Example Project

Affected Group:
Project with Security Scanning configured:

What is the current bug behavior?

When a group has no projects, results from security scans configured in subgroups will not be visible in the vulnerability report until a project is created within the affected group.

What is the expected correct behavior?

The group vulnerability report should display results from all subgroup projects regardless of whether a project exists in the affected group or not.

Relevant logs and/or screenshots

N/A

Output of checks

This bug happens on GitLab.com

Solution

The culprit is the has_projects property that's being computed in security_features_helper.rb#L34. This determines whether or not a group contains projects, but it only looks for top-level projects and does not include sub-groups. This results in the property evaluating to false when displaying a group's dashboard if the group does not have projects but has sub-groups that do.

The solution involves changing has_project's implementation so that it includes sub-groups in its lookup. We can do this by leveraging the Project.for_group_and_its_subgroups method which find a group's projects, including sub-groups.

Edited by Paul Gascou-Vaillancourt