Group level Vulnerability Export API does not uniquely identify projects in nested groups
Summary
The CSV report generated by the Group level Export Vulnerabilities API (/security/groups/:id/vulnerability_exports) does not contain enough information in exported rows to uniquely identify the project which a vulnerability applies to, specifically when the project exists in a nested group.
In the first instance, there is no field in the report which contains the Gitlab Project ID. Nor is there a field which contains the specific vulnerability ID. The only fields which identify the project are a combination of "Project Name" and "Group Name", however the "Group Name" field only contains the name of the immediate parent group, not the full hierarchy/path between the project and the "root" Group of the query (specified by the group ID in the POST URL). The result is that projects within nested groups are not clearly identifiable based on the information in the CSV records, and leads to a situation where groups with duplicate names in nested hierarchies could be confused.
Consider the following example group/project structure:
ROOT -> Mobile -> Frontend -> shared-libs
ROOT -> Mobile -> Backend -> shared-libs
ROOT -> Website -> Frontend -> shared-libs
ROOT -> Website -> Backend -> shared-libs
The layout of groups and projects follows a sensible and predictable hierarchy, but for any given vulnerability affecting one of these projects, in the CSV export it would be impossible to determine whether it applied to the Mobile or Website code base.
This flaw severely limits the usefulness of the vulnerability export for security teams which rely on it for attribution, reporting, analysis, and integration with third party tools.
Steps to reproduce
- Generate a Group level vulnerability export via the API (/security/groups/:id/vulnerability_exports) or web UI (https://gitlab.com/groups/:id/-/security/vulnerabilities)
- Wait for the report to finish generating and download the CSV file
- Open the CSV, observe that the "Group Name" field only contains the immediate parent and there is no other field or combination of fields which can be used to reliably and uniquely identify the project.
Example Project
N/A - applies to any project in nested group
What is the current bug behavior?
The CSV file produced by the vulnerability export report does not contain any unique identifying information for the affected project
What is the expected correct behavior?
Each record in the CSV export should include AT LEAST a Project ID field which contains the unique numeric ID that can be used to programmatically reference the project (e.g. via /security/projects/:id/vulnerability_exports).
Ideally, the "Group Name" field should include the full group hierarchy/path for the as well, or failing that, a new field should be introduced which includes this information.
Relevant logs and/or screenshots
N/A
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
N/A
Results of GitLab application Check
N/A
Possible fixes
N/A
Implementation Plan
-
Add a namespace_path
mapping to the CSV exporter to export the exact namespace_path for the project as we would use in our GraphQL API's. -
Implement this behind a feature flag to avoid any compatibility issues for users.