Security Manager Default Role

Problem to solve

Because there is not a default role that maps to a security persona, managing permissions for security-related features is overly complex. Complexity leads to misconfiguration/over-permissioning.

• Customers cannot easily understand which role to assign to their AppSec team members.
• Without this role, security teams have more access than needed, violating the principle of least-privilege (Security personas may not need Owner-level or maintainer-level permissions)
• Without a default security role, our DevSecOps platform is designed well for developers, but less usable for security teams
• Sec section teams must spend time inefficiently considering roles and permissions for the features they build
• As GitLab makes improvements to make security configuration more scalable (by moving more toward instance-level and group-level configuration settings, rather than project-level), it's critical to have a default role that can be given these permissions.

Proposal

• Add a Security Manager default role.
• Follow same implementation path used to add new "Planner" default role:
  • 1-2 milestones Validate permissions and naming via UX research
  • 1 Milestone for eng spike
  • 1 Milestone for dev (dev work to be done by groupsecurity platform management )

Scope

Must Have

• The following permissions:
  • Vulnerability Management
    • admin_vulnerability
    • read_dependency
    • read_vulnerability
  • Security Policy Management
    • manage_security_policy_link
  • Security Testing Management
    • admin_security_testing
  • Auditor User
    • (read-only access to all project and group audit events)
• More permissions to be validated

Intended users

• Ultimate AppSec admins