Change Vulnerability Status - Customizable Permissions
Problem to solve
Today users don't have the ability to separate out the duties between the engineering security teams in a way that adheres to the Principle of Least Privilege. Security teams need to be able to change the vulnerability status, but don't necessarily need to make changes directly to a code base.
Intended users
Proposal
-
Add the following customer permissions to a custom role (built on top of the Reporter role as a base):
-
Change vulnerability status
- admin_*
-
- Today users can change the vulnerability status if they have Developer or higher permissions. This change removes the requirement of a Developer role and requires the permission
Change vulnerability status
. -
Remove the following permission from the current
Developer
andMaintainer
roles:-
Change vulnerability status
Note: this is a breaking change.
-
- Create a rake task that adds
Change vulnerability status
to either theDeveloper
andMaintainer
roles for Ultimate customers using customizable permissions that want this permission re-added to this role after the change.
Further details
- The new customizable roles framework permissions is additive only. Instead of
Change vulnerability status
permission included as a part of both theDeveloper
andMaintainer
roles, users will need to do something likeReporter
+Change vulnerability status
. - admin_* is the equivalent of read/write, while read_* is the equivalent of read only.
Documentation
Availability & Testing
Available Tier
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.