Security Risk Management - Introduce Application/Business-Unit View
Security Risk Management - Introduce Application/Business-Unit View
Today, the scope of reports and policies is tied to projects and groups.
AppSec engineers may structure their apps/business units/ areas of responsibility not necessarily according to the GitLab structure. We need to assume that Each of our AppSec users have a scoped application or Business unit, on which they need to assess the application risk. The scope of an application can be:
- Group and its subgroups and projects
- Group, its subgroups, and additional projects outside the group
- Separate projects from seperate groups.
This will also cover Add support for the Vulnerability Report and De... (gitlab-org#10048) which is a highly requested feature
Initial DRAFT requirements:
- A View is a collection of groups and projects, which do not have to be related.
- Each user will be asked to define their first view when going to the new dashboard / an alternative approach would be to set their current scope they are (Group / Project) in as the default view.
- Another option - list of predefined Views
- Admins can define up to 10 views which will shared between all relevant users with permissions.
- Users can define up to 10 views (this number can be changed)
- Each user will be able to save/share their view with others (the other must have at least the same access permission to view all these projects/groups)
- Views will be supported for Vulnerability Report, Dependency list and Security Dashboards.
- Views will have CRUD capabilities
To consider:
- Support pre-defined views by compliance frameworks - this will answer this requirement - Filter by Compliance Framework Label on the Vul... (gitlab-org&14759)
Previous issues:
Addition feedback:
Currently - for companies like GitLab - the dashboard is relatively unusable due to the sheer volume of projects that aren't relevant to our actual production workload. It'd be great to provide filtering on Deployment Tier and on projects that have created GitLab Releases.
We actually have this already, though it hasn't received a ton of support: @wandering_person the idea shared by Carrefour (in the slides above) goes way beyond this. And WorldLine (another customer) expressed the exact same need yesterday. The need is not to have one single static dashboard with a fixed set of projects. It really is to have many customizable dashboards.
Carrefour for example has 19k projects. They need to be able to say:
- here is the set of projects, groups, applications, compliance frameworks that I want to include in this visualization
- For these 2 customers, "application" as a very common meaning: a set of projects, which may leave in different groups. Being able to identify them through tags, name pattern/regex or something like this would be super helpful)
- Like @poffey21 said being able also to exclude projects from groups is meaningful (by environment, by name regex, ...)
- WorldLine for example has tons of personal projects and groups. Filtering them all by saying "I want/don't want groups/projects matching this pattern" is very important for them.
- here is the widgets that I want to see (vuln score, pie chart by OWASP Top 10, MITRE/SANS CWE Top 25, 10 oldest critical vuln, ...)
- save this configuration for later re-use/sharing
Additional customer issues:
- Show closed items
- View on a roadmap
- Show labels
- Show closed items
Related to
- Issuegitlab-org/gitlab#520562Category:Custom Dashboards Foundation UX devops plan group platform insights section dev spike type feature
- IssueOpengitlab-org/gitlab#438630Category:Team Planning GitLab Ultimate devops plan documentation feature addition group project management section dev type feature
- Epicgitlab-org#1004824Jan 13, 2025 – Jan 13, 20260 1 0GitLab Ultimate Secure UX Shared customer devops security risk management documentation feature addition group security insights section sec secure experience type feature
Activity
- Edited by Becka Lippert
@dagron1 @smeadzinger Is this dependent on the cells initiative? Or would this live at the Security Center level? (see screenshot below) Or something else?
- Admins can define up to 10 views which will shared between all relevant users with permissions.
With the Security Center I doubt that would allow for this, but I could be wrong.
Users can define up to 10 views (this number can be changed) Each user will be able to save/share their view with others (the other must have at least the same access permission to view all these projects/groups)
This sounds related to Design: Customizable saved views (gitlab-org/gitlab#267572 - closed), but we should discuss how this is related (or not) before I add my design weight here.
Setting the scope of projects, subgroups, and groups would be fairly straightforward from a design POV (through the use of filters), but the design effort for saving the view depends on whether we can use the designs from Customizable saved views.
- Edited by Dean Agron
Thanks @beckalippert - I believe cells is more architecture oriented to improve scale, performance and reliability
ans less relevant to this area.(Fixing after @bwill comment).Re customizable views - is it for grouping of groups/projects or for saving filters?
- Edited by Brian Williams
@dagron1 Part of cells 1.0 will be the creation of organizations, which will allow multiple top-level namespaces to be grouped together. We can work on this feature before organizations are complete, but we will not be able to include projects from outside the current top-level group until organizations are done.
@Bryan.Kelly This is what I was relying on
- Organizations provide logical separation: They group related users, groups, and projects under a single entity, allowing for better management and isolation of resources.
- Cells provide physical separation: Each Cell is an independent set of infrastructure components that can host multiple Organizations.
I understand those are coupled.
Per your comment:
we will not be able to include projects from outside the current top-level group until organizations is done.
Once we will move forward, we will map all limitations. Thanks for noting
Re customizable views - is it for grouping of groups/projects or for saving filters?
@dagron1 It's for saved views; eventually, the idea that a "view" can consist of saved filters, keyword searches (when keyword search is introduced), and/or groupings (using the "Group by" functionality).
- Edited by Dean Agron
Ok, in this case, we are defiing views as two seperate things - I define them as collection of GitLab Groups and Projects, and you define them as collection saved filters, vulnerability grouping, etc. Those are two different objects.
cc:@smeadzinger