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)
-
Vulnerability Management
- More permissions to be validated
Intended users
- Ultimate AppSec admins