Investigate project "topics" as a way to filter and view data on vulnerability reports

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Release notes

Problem to solve

Customers with large numbers of projects need a better way to filter by specific sets on Group-level (and Security Center) Vulnerability Reports (and ideally Security Dashboards). For instance, I may wish to view only vulnerabilities for my highest sensitivity production microservices. You can filter by project today but you must search for and select each desired project one at a time. This is time consuming, tedious, and error prone if you need a specific set of projects—especially if you have dozens or hundreds of projects underneath the group whose vulnerability report you are using.

Intended users

Metrics

User experience goal

Proposal

Investigate Topics to see if they can meet the need of a durable, repeatable filter criteria across projects.

Further details

At a high level, requirements for any such filtering mechanism include:

• Works on both Group-level and Security Center. Note that Security Center allows users to add projects from any namespace to which they have permissions, not just within a single top-level/root group.
• Filters should be limited to the broadest scope of the current context. That means for Group Vulnerability Reports, you can only search and filter on tagged projects in that group or any child sub-group. For Security Center, it is any project accessible to the user.
• The filter parameter must be accessible to the same or lower (less permissive) role as what is required to access a project in a Vulnerability Report. In other words, if I can see vulnerabilities and the Vulnerability Report for a specific project, I should also have at least read-only access to the parameter that will be used to filter on Group and Security Center reports.

The current Topics implementation seems very basic and has several limitations that must be addressed before it would present a workable solution to act as the desired filter criteria:

• Topics currently seem entirely open; you can search topics across all public projects and private projects to which you have access, regardless of namespace. This will be extremely noisy, especially on SaaS.
• Topics are not case-sensitive. You can see on gitlab.com examples such as python and Python. This will make Topics difficult to use a SSOT if you can accidentally create duplicates that are slightly different.
• Topic creation and editing is done merely in a text input. This is too prone to error and not user-friendly if used for a SSOT for filtering. One suggestion is to separate topic assignment from creation, much like labels. The UX for assigning topics could then mirror label assignment.
• Topic creation and editing is too permissive. This should be restricted to project Owners and possibly Maintainers.
• Topic creation, editing, and assignment needs to have a full audit history.
• There is no good way to see all projects in a hierarchy with their respective topics.
• All functionality associated with topics needs to have equivalent GraphQL capabilities.

Custom requests

• Large (>3000) Ultimate customer:

It would be beneficial to allow groups traditionally in charge of reporting / compliance to provide controls without impacting the hierarchy to which projects are located. This would minimise the impact a organisational restructure would have on a given code base, since group/subgroups form the project namespace

Permissions and Security

Documentation

Availability & Testing

Available Tier

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.