### Problem to solve Before GitLab 17.0, anyone with at least Developer access could dismiss vulnerabilities in any of the Security Dashboards. This created a lack of accountability and oversight in managing vulnerabilities. In GitLab 17.0 or newer, the default access is moved to the Maintainer RBAC role. See https://docs.gitlab.com/user/application_security/vulnerabilities/#change-the-status-of-a-vulnerability. _{Note: This issue content has been updated because Google search AI answers are treating it as if it were current. See [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/208482#note_2531639432).} ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [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) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### Further details We already have [Security Approvals](https://docs.gitlab.com/ee/user/application_security/index.html#security-approvals-in-merge-requests) at the Merge Request level, where a group of users is required to approve any finding with a Critical, High, or Unknown severity. Even dismissed findings with these severities still requires approval before merging is allowed. However, we don't have any control on dismissals outside of the MR. Anyone with Developer access can freely dismiss vulnerabilities in Vulnerability Reports (formerly Security Dashboards, which show vulnerabilities already in a project's `default` branch). This change can go under the radar of the Security Team because we don't yet have an audit trail and no approval is required to dismiss a vulnerability. ### Proposal We need a way to optionally require approval before dismissing a vulnerability from a Project, Group, or Instance Vulnerability Report. We need to consider having this be a setting or rule that can by applied top-down so that users with many hundreds or thousands of projects can enable it globally. Overriding or making specific adjustments at the Group and/or Project level will still be necessary. It may not be the right long-term approach but we should consider whether we can leverage the existing security approver groups. We might use them as the same approvers for vulnerability dismissal approvals. This issue is to gather discussions to solve this problem. ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> TBD ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> TBD ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> TBD ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> - Better isolation of privileges for security interactions ### What is the type of buyer? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> ~"GitLab Ultimate" ### Links / references /cc @andyvolpe following our discussion today.