Skip to content
Snippets Groups Projects
Open Security Risk Management - Introduce Application/Business-Unit View
  • Security Risk Management - Introduce Application/Business-Unit View

  • Security Risk Management - Introduce Application/Business-Unit View

    Open Epic created by Dean Agron

    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:

    Previous issues:

    Addition feedback:

    @poffey21

    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.

    @odupre

    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:

    Edited by Dean Agron

    Child items
    0

  • View on a roadmap
  • No child items are currently assigned. Use child items to break down work into smaller parts.

    Linked items 3

  • Related to

    Activity

    • All activity
    • Comments only
    • History only
    • Newest first
    • Oldest first
    • Dean Agron changed the description ·
    • Dean Agron added #2469 as parent epic
    • Dean Agron changed the description ·
    • Dean Agron marked this epic as related to gitlab-org#10048
    • Brian Williams changed title from Security Risk Management - Introduce Application\BU Scope to Security Risk Management - Introduce Application / Business Unit Scope
    • Dean Agron changed the description ·
    • Dean Agron changed the description ·
    • Becka Lippert changed the description ·
      • 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?

        Screenshot 2025-01-02 at 3.35.54 PM.png

        • 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 Becka Lippert
      • Dean Agron
        Author

        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 Dean Agron
      • 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.

        Edited by Brian Williams
      • Dean Agron
        Author

        @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

      • Becka Lippert

        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).

      • Dean Agron
        Author

        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

        Edited by Dean Agron
      • Please register or sign in to reply
    • Dean Agron changed the description ·
    • Dean Agron changed title from Security Risk Management - Introduce Application / Business Unit Scope to Security Risk Management - Introduce Application/Business-Unit View
    Loading Loading Loading Loading Loading Loading Loading Loading Loading Loading