### Problem to solve The Scan Result Policy Action currently supports individual approvers or a group of users. However, when a customer has projects with lower criticality or the scan results detect a vulnerability of low criticality (I.e., Low/Medium), they want to require an approver from the project based on the role (I.e., owner/maintainer), rather than a separate AppSec group. Maintaining a separate subgroup for every project or adding individuals to the approval requires a lot of manual configuration and upkeep. Adding in the ability for the approval group to choose either a Group/Individual or based on RBAC would make it much easier to manage compliance standardization across all projects. ### Release post With role based approval actions, you can configure scan result policies to require approval from GitLab-supported roles, including Owners, Maintainers, Developers, Reporters, and Guests. This gives you additional flexibility over requiring individual approvers or defined groups of users, making it easier to enforce policies based on roles you already leverage in GitLab, at scale, especially across large organizations. <img src="/uploads/f276e8699d5abf5a3739f7147df2ab6b/image.png" height="100"> ### Intended users * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) ### Design Proposal **We do not have to have three phases, it is ok if we directly jump to phase 2 or 3 directly ;)** **Figma:** https://www.figma.com/file/bWjOIMtS46AXylghTjUsbU/UX-theme-vision-approval?node-id=78%3A19697 **Some component of this design is still using the old ones, please use what is available when develop** | Phase-1 | Phase-2 |Phase-3 | | ------ | ------ |------ | | Multi selection for roles in this phrase. Number of selection is only for project level | Multi selection for roles in this phrase. Number of selection is only for project level| Single selection for roles in this phrase. Number of selection is only for project level| | || ) | ### Permissions and Security ### Documentation ### Availability & Testing ### What does success look like, and how can we measure that? ### What is the type of buyer? ~"GitLab Ultimate" ### Is this a cross-stage feature? ### Links / references *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->