SAST Vulnerability Resolution – Permission AppSec Teams to Configure SAST VR and Other Sec AI Agents/Flows On
## TL;DR
Enable security teams to turn on and configure SAST Vulnerability Resolution across their portfolio without requiring Maintainer/Owner roles on every individual project.
A follow-up iteration will extend the same model to Vulnerability False Positives.
## Overview
Today, only project Maintainers and Owners can enable and configure SAST Vulnerability Resolution on each individual project. In most enterprises the Vulnerability Management and/or AppSec team is the one responsible for Vulnerability Remediation, but they do not have the right permissions to modify the SAST Vulnerability Resolution configuration for their projects. Changing roles for hundreds or thousands of projects is not feasible for organizational and governance reasons.As a result, customers can not enable SAST Vulnerability Resolution or scale it across their platform.
With this epic we will focus on developing a way that the the Vulnerability Management and/or AppSec team to manage SAST VR.
## Business Value
With this epic we will give Vulnerability Management/AppSec teams a controlled way to enable and configure SAST VR (and other Sec AI agents) without broad admin or code-write permissions. This will help them to drive remediation workflows and SAST Vulnerability Resolution across their platforms. This way our customer get consistent, centrally defined SAST VR policies.
The goal is to increase SAST Vulnerability Resolution Adaption and GitLab Duo Token consumption, [starting with these customers](https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3262645200).
## Scope
### In Scope - First Iteration - %"19.1"
* Project-level enablement without Maintainer/Owner
* Allow designated security users (via new permission(s), e.g. `update_sast_vr_setting` granted to Security Manager, Maintainer, and Owner) to enable and configure SAST VR at the project level.
* Visibility and basic governance
* Surface who controls SAST VR and from where so app teams and security teams understand ownership.
* Provide basic audibility for SAST VR enable/disable changes at the project level.
*
### Out of Scope
* Redesigning the entire GitLab role model or adding a broad new global role type.
* Custom roles support for the new permission (deferred per https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3324237411).
* Group/subgroup/organization/instance level configuration (delivered separately via https://gitlab.com/groups/gitlab-org/-/work_items/21766 when delivered, it will mirror the existing group-level cascading pattern).
* Centralizing all Duo flows and agents (scope is Sec AI agents first).
* Granting central security teams broader project administration or code-write capabilities beyond what is needed to manage SAST VR.
* Vulnerability Details page - the SAST VR action button stays as-is under `resolve_vulnerability_with_ai` (developer+).
* Developer-based enablement as an alternative path (to be evaluated separately).
### Future Scope
- Vulnerability False Positive Detection - apply the same permission model in the next iteration, with attention paid during SAST VR implementation to generalizing the solution (e.g. a generic permission name) so this can be added with minimal overhead ([note_3343146399](https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3343146399), [note_3324237411](https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3324237411)).
- Multi-level configuration scope beyond project level (delivered separately, e.g. via &21766). When delivered, it will mirror the existing group-level cascading configuration pattern:
- Group/subgroup level configuration.
- Organization/instance level configuration.
- Developer-based enablement as an alternative path (to be evaluated separately).
## Success Criteria
How will we know this epic is successful? Define measurable outcomes.
- [ ] Designated security users can enable and configure SAST VR on projects without holding Maintainer/Owner
- [ ] SAST Vulnerability Resolution can be configured at project level
- [ ] Increase in SAST Vulnerability Resolution enablement across target enterprise customers
- [ ] Increase in Duo token consumption tied to SAST VR
- [ ] Audit log entries exist for central SAST VR enable/disable and configuration changes
- [ ] Security Managers should be able to both configure and use this feature.
## Open Questions
<table>
<tr>
<th>Question + Person who asks</th>
<th>Owner</th>
<th>Status</th>
</tr>
<tr>
<td>
When it comes to deliverables, will this epic be divided into phases/iterations? And if so, what will this look like? Or is what the current epic describes the only thing we need to build to successfully implement this? - @charlieeekroon
</td>
<td>
@mclausen35
</td>
<td>Open</td>
</tr>
<tr>
<td>
I am assuming we will need to change documentation. And, if that's indeed the case, is this the documentation that needs changing https://docs.gitlab.com/user/application_security/vulnerabilities/agentic_vulnerability_resolution/ - @charlieeekroon
</td>
<td>
@mclausen35
</td>
<td>Open</td>
</tr>
<tr>
<td>
Under `In scope` it states:
* _Existing design patterns may be sufficient here_
But the initial epic description also has an entire "Designs" subheading. What design patterns are we referring to? UI or architectural? Are designs in, or out of scope for this epic? - @charlieeekroon
</td>
<td>
@mclausen35
</td>
<td>Open</td>
</tr>
<tr>
<td>
In the original description it stated under `business case`: _"Secondarily, this may support the broader ASPM / remediation orchestration narrative."_. What is meant with this? Is this something we need to actively take into account? Or are these nice-to-have side effects? - @charlieeekroon
</td>
<td>
@mclausen35
</td>
<td>Open</td>
</tr>
<tr>
<td>
On the business value: _"Increase SAST VR adoption and Duo token consumption (starting with these _[_customers_](https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3262645200)_). Secondarily, this may support the broader ASPM / remediation orchestration narrative."_
What does this mean exactly? Are we focused on increasing those metrics specifically for these customers for now, or more broadly? What are the current numbers, and what makes this project a success? What numbers are we aiming for? - @charlieeekroon
</td>
<td>
@mclausen35
</td>
<td>Open</td>
</tr>
</table>
## Timeline & Milestones
- **Target Milestone:** %"19.1"
- **Status**: \[On Track / Needs Attention / At Risk\]
## Deliverables
```glql
display: table
query: epic = &21725 and type = Issue
fields: title, status, milestone, assignees
sort: milestone asc
title: Child Issue Tracking
```
## Decision Log
<table>
<tr>
<th>Date</th>
<th>Decision</th>
<th>Rationale</th>
<th>Owner</th>
</tr>
<tr>
<td>22 April, 2026</td>
<td>
The use of SAST VR on the vulnerability details page stays as-is under `resolve_vulnerability_with_ai`
</td>
<td>
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3276486074
</td>
<td>
@mclausen35
</td>
</tr>
<tr>
<td>22 April, 2026</td>
<td>Security Managers should be able to both configure and use this feature.</td>
<td>
#21725 (comment 3276889805)
</td>
<td>
@mclausen35
</td>
</tr>
<tr>
<td>29 April, 2026</td>
<td>We will create a new permission rather than re-using an existing one. The security manager, maintainer and owner will get this permission.</td>
<td>
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3300130156 and https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3324237411
</td>
<td>
@m-omokoh , @mclausen35 , @ajbiton
</td>
</tr>
<tr>
<td>29 April, 2026</td>
<td>
We will gate the specific configuration behind a new permission. For example; `update_sast_vr_setting`. We will grant the `security_manager` that permission
</td>
<td>
This is consistent with the principle the role is built on: precise access for security professionals without broader permissions they do not need.
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3300054243 and https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3300130156)
</td>
<td>
@m-omokoh , @jayswain
</td>
</tr>
<tr>
<td>29 April, 2026</td>
<td>We will not give the security manager role access to the global project settings.</td>
<td>
We would give more access than the role should have.
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3300130156
</td>
<td>
@m-omokoh
</td>
</tr>
<tr>
<td>29 April, 2026</td>
<td>We will not create a new page with the configuration. -</td>
<td>
This will be more overhead than it warrants.
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3300130156
</td>
<td>
@m-omokoh
</td>
</tr>
<tr>
<td>30 April, 2026</td>
<td>
~"group::security insights" owns:
* Implementing the setting/permission like `update_sast_vr_setting` on the setting page and protect it behind a permission
* Grant the new permission to the `maintainer` role.
</td>
<td>
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3305012721
</td>
<td>
@jayswain
</td>
</tr>
<tr>
<td>30 April, 2026</td>
<td>
~"group::authorization" owns:
* letting the relevant parts of the settings page render for users holding only the granular permission
</td>
<td>
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3305012721
</td>
<td>
@jayswain
</td>
</tr>
<tr>
<td>8 May , 2026</td>
<td>The role will not be customizable for the first iteration</td>
<td>
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3324237411
</td>
<td>
@ajbiton
</td>
</tr>
<tr>
<td>12 May, 2026</td>
<td>
We will focus on delivering this on `project` level. We will deliver this on `group` level in https://gitlab.com/groups/gitlab-org/-/work_items/21766#top
</td>
<td>
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3328833019
</td>
<td>
@mclausen35
</td>
</tr>
<tr>
<td>12 May, 2026</td>
<td>
We will mirror the currently, already existing group-level cascading model. This will be part of https://gitlab.com/groups/gitlab-org/-/work_items/21766#top
</td>
<td>
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3328833019
</td>
<td>
@mclausen35
</td>
</tr>
<tr>
<td>12 May, 2026</td>
<td>We do not focus on organization/instance level during this epic</td>
<td>
https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3328833019
</td>
<td>
@mclausen35
</td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</table>
## Where does this currently live in the plaftorm?
###### Configuration on Project level:
* Settings --\> General --\> Expand Gitlab Duo --\> "Turn on SAST vulnerability resolution workflow" toggle.
{width="690" height="114"}
###### Configuration on Group level:
* Settings --\> GitLab Duo --\> Change configuration --\> Flows --\> Allow flow execution --\> Check "Resolve SAST Vulnerability"
{width="900" height="412"}
## Resources
TBD
- Design: \[link\]
- Documentation: https://docs.gitlab.com/user/application_security/vulnerabilities/agentic_vulnerability_resolution/
<!--**Problem to Solve:** Today, SAST Vulnerability Resolution (SAST VR) can only be enabled and managed by users with Maintainer/Owner permissions on each individual project. In many enterprises the Vulnerability Management / central security team is accountable for vulnerability remediation but does not hold Maintainer/Owner roles on application projects, and changing roles at scale is not feasible for organizational and governance reasons. As a result, customers can't turn SAST VR on or scale it across their portfolio.
**Business Case:** Increase SAST VR adoption and Duo token consumption (starting with these [customers](https://gitlab.com/groups/gitlab-org/-/work_items/21725#note_3262645200)). Secondarily, this may support the broader ASPM / remediation orchestration narrative.
**In Scope (Requirements)**
* Central enablement without Maintainer/Owner
* Allow designated security users (or similar) without Maintainer/Owner on each project to enable and configure SAST VR, including key options (e.g., which projects/branches it applies to).
* Alternatively, consider pushing for developer-based enablement.
* Multi-level configuration scope
* Support turning SAST VR on and managing its configuration at: Project level , Group/subgroup level, Organization/instance level in the future
* Visibility and basic governance
* Surface who controls SAST VR and from where (local vs central config) so app teams and security teams understand ownership.
* Provide basic auditability for central SAST VR enable/disable and configuration changes.
* Existing design patterns may be sufficient here
**Out of Scope**
* Redesigning the entire GitLab role model or adding a broad new global role type.
* 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.
**Designs**
* Consider the following directions to solve for this problem
* **Remediation orchestration UX as the control plane**
* **Custom roles / scoped security roles**
* **More granular actions/permissions**
* **Developer-facing activation paths / workarounds**
* Consider lightweight UX patterns that:
* Present SAST VR setup to **developers / Maintainers** when a central security team cannot yet turn it on directly (e.g., guided prompts or requests).
* Make it easy for app teams to “accept” or “apply” a centrally defined SAST VR configuration when permissions are constrained.-->
epic