<!-- The first four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. --> ### Problem to solve <!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." --> When a security vulnerability was previously detected but is no longer found in a subsequent scan, the status of the vulnerability will remain unchanged. This forces an individual to have to manually set the status to "Resolved" in order to accurately describe the status of the vulnerability. ### Proposal <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> A new policy type _Vulnerability Management policy_ at the project/group/instance level that gives GitLab the permission to automatically resolve security vulnerabilities when they are no longer being detected in subsequent scans. This can be further broken down to allow selecting specific scanners to allow automatic resolution. That way, teams can decide more granularly which removed vulnerabilities need a person to review before closing versus which ones can be trusted to the automation. **Note**: The previous solution of a setting has been replaced with a [new policy-based approach](https://gitlab.com/gitlab-org/gitlab/-/issues/233846#note_717504640). ### Further Details For Product companies like GitLab, it makes sense to keep track of vulnerabilities over time. One version could have been shipped with a critical vulnerability, which means a new security release even though the security issue has been remediated since. For SaaS companies, the workflow is different. With Continuous Delivery, the state of the service is often the state of the latest pipeline in `master` (or any other main branch). In this case, the users don't really care about what occurred in the past. They would probably use more [notifications](https://gitlab.com/gitlab-org/gitlab/-/issues/4905) in this case than this dashboard. ### Requirements ## Requirements - The auto-resolved vulnerability should have an activity item stating that it was resolved because of X policy (and ideally, a link to the policy).