SAST Vulnerability Resolution - Backend (#21971) · Epics · GitLab.org

SAST Vulnerability Resolution - Backend

_This epic is still a work in progress while we are refining the specs_ ## TL;DR ~"group::security insights" backend work to allow non-Maintainer/Owner users — initially security_manager, later custom roles — to enable and configure SAST Vulnerability Resolution (`duo_sast_vr_workflow_enabled`) at the project level only, without granting broader project-administration access. ## Open Questions | Question | Owner | Status | |----------|-------|--------| | Do we want a custom-role? In the `out of scope` of the parent epic it was mentioned we do not want to create a new global role type, does `custom-role` fall under this? | | | | | | | ## Scope (provisional) _Scope is provisional and depends on the open questions above._ ### In Scope - Add the ability in `config/authz/abilities/...` and reference it in the relevant role YAMLs - Replace the `admin_project` gate with the new ability for the SAST VR toggle in: - `ee/app/controllers/ee/projects_controller.rb` - `ee/app/graphql/mutations/projects/project_settings_update.rb` - REST params in ee/lib/ee/api/helpers/projects_helpers.rb (lines 30, 64) — ensure the policy check on Projects::UpdateService honours the new ability ### Out of Scope - Organization/Instance level - Redesigning the entire GitLab role model - Page-level rendering of project settings for non-admins – gitlab~33056472 will focus on this - Centralizing all Duo flows and agents in this iteration (scope is Sec AI agents first) - Granting central security teams full project administration or code-write capabilities beyond what is needed to manage SAST VR. ### Future scope - [ ] At group level, a `security_manager` can configure the cascading SAST VR setting for descendant projects. ## Phase _Explain which phase of the parent epic this work belongs to._ _WIP_ **_Epic Phase:_**\_ Phase X – \[Phase Name\]\ **Parent Epic:** #epic-link\_ ## Problem Statement Today the `duo_sast_vr_workflow_enabled` toggle lives on the project General settings page, which is gated by `admin_project`. AppSec teams typically have `security_manager` (Reporter-equivalent + security additions) and cannot toggle this. Customers cannot roll SAST VR out across their portfolio without granting Maintainer/Owner everywhere, which is unacceptable. Per agreement on the parent epic (see thread), the chosen approach is to gate this single setting behind a new granular permission, rather than opening up project settings broadly or building a new page. ## Feature Flag - [x] Required\ **Flag name:** `sast_vr_security_manager_config` (TBD) **Default state:** Enabled / Disabled\ **Rollout plan:** Optional gradual rollout details. ## Success Criteria (Provisional) - [ ] A user with the `security_manager` role on a project can toggle `duo_sast_vr_workflow_enabled` via UI, REST, and GraphQL without holding Maintainer/Owner. - [ ] The same user cannot modify any other project setting via the same endpoints. - [ ] An audit event is recorded on every enable/disable and configuration change. - [ ] A user without the ability still receives the existing 403/`admin_project` error. - [ ] All three surfaces (UI form, REST `PUT /projects/:id`, GraphQL `projectSettingsUpdate`) enforce the same rule. ## Resources - Documentation: \[link\] - Relevant issues, discussions etc.

epic