Auto-resolve vulnerabilities when not found in subsequent scans (#5708) · Epics · GitLab.org

Auto-resolve vulnerabilities when not found in subsequent scans

### Release notes GitLab's [security scanning tools](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools) help identify known vulnerabilities and potential weaknesses in your application code. Scanning feature branches surfaces new weaknesses or vulnerabilities so they can be remediated before merging. In the case of vulnerabilities already in your project's default branch, fixing these in a feature branch will mark the vulnerability as no longer detected when the next default branch scan runs. While it is informative to know which vulnerabilities are no longer detected, each must still be manually marked as Resolved to close them. This can be time consuming if there are many of these to resolve, even when using the new [Activity filter](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#activity-filter) and [bulk-changing status](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#change-status-of-vulnerabilities). We are introducing a new policy type _Vulnerability Management policy_ for users who want vulnerabilities automatically set to Resolved when no longer detected by automated scanning. Simply configure a new policy with the new Auto-resolve option and apply it to the appropriate project(s). You can even configure the policy to only Auto-resolve vulnerabilities of a certain severity or from specific security scanners. Once in place, the next time the project's default branch is scanned, any existing vulnerabilities that are no longer found will be marked as Resolved. The action updates the vulnerability record with an activity note, timestamp when the action occurred, and the pipeline the vulnerability was determined to be removed in. ### Problem to solve  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. ### Current work arounds - @sam.white [created a job](https://gitlab.com/groups/gitlab-org/-/epics/5708#note_1678481363 "Auto-resolve vulnerabilities when not found in subsequent scans") that you can add to your pipelines, `auto_resolve_vulnerabilities` will resolve vulnerabilities that are no longer detected. - https://gitlab.com/gitlab-org/gitlab/-/issues/432169+ is planned for %16.8. This change will update the default filters on the **project** and **group** vulnerability report to include `still detected`. By default you won't see vulnerabilities that are `no longer detected` when you open the vulnerability report. ### Proposal Add new auto-resolve functionality in two main parts: * a new policy type _Vulnerability Management policy_ that gives GitLab the permission to automatically Resolve security vulnerabilities when they are no longer being detected in subsequent scans. * **Note**: this new policy capability will be implemented in the [Policies UI](https://gitlab.com/groups/gitlab-org/-/epics/5362 "Allow Users to Edit yaml-mode Scan Execution Policies in the Policy UI") as well as any supporting ~backend changes. * a new icon on the Vulnerability Report and option in the Activity filter for selecting Auto-resolved vulnerabilities ### MVC _The MVC for auto-resolve will only consider the project level. In the future, the policy can be added to the Group (and eventually _[_Workspace_](https://gitlab.com/groups/gitlab-org/-/epics/4257 "Organization/Workspace to replace instance-level functionality with group-level features")_) level._ The MVC encompasses: - A new policy type for the vulnerability management, including a new tile on the new policy selector - The policy editor which allows configuring multiple rules for which severity and report type combinations vulnerabilities are allowed to be resolved. This can be done both in a form (Rules mode) as with pure YAML with basic validation. - Listing and filtering this new type in the policies list - Showing policies of this type in a humanized way in the drawer on the policy list - Persisting and querying this new policy type - The mechanism that performs that auto-resolving during ingestion based on the configured policies - A resolve state transition performed by some kind of Security Policy Bot Check the [frontend](https://gitlab.com/groups/gitlab-org/-/boards/1754666?label_name%5B%5D=group%3A%3Athreat%20insights&label_name%5B%5D=frontend&epic_id=243778) and [backend](https://gitlab.com/groups/gitlab-org/-/boards/1754666?label_name%5B%5D=group%3A%3Athreat%20insights&label_name%5B%5D=backend&epic_id=243778) issues for the implementation details. Post MVC work can be found in this epic: https://gitlab.com/groups/gitlab-org/-/epics/15697 #### Why start with Project level? The MVC will only consider project level vulnerability management policies 1. to reduce the scope of the MVC 2. to limit the amount of vulnerabilities that might need to be resolved The project and group-level vulnerability policy type are guarded by respective feature flags `vulnerability_management_policy_type` and `vulnerability_management_policy_type_group`. When these feature flag is enabled it: 1. shows vulnerability management policy as option in the new policy selector 2. loads vulnerability management policy types in the policy list 3. allows filtering by vulnerability management policy type in the policy list ### Requirements **Functional** - [ ] Vulnerabilities on a given project will only be auto-resolved when a properly-configured policy is in place. - [ ] Policies can be configured to only auto-resolve vulnerabilities from specified scan types/scanners. - [ ] Policies can be configured to only auto-resolve vulnerabilities of specific severities. - [ ] The new policy capability and filter are available to gitlab.com and self-managed users. - [ ] Policies are evaluated for regular pipeline security scans jobs as well as continuous and on-demand scan types. - [ ] When enabling the policy on a project, the auto-resolve behavior will begin the next time scans run against its `default` branch. - [ ] When disabling or removing the policy, no new pipelines (or scans) will trigger the auto-resolve behavior. It is acceptable that any pipeline or scan currently running against `default` when the policy is removed will still auto-resolve any relevant vulnerabilities. - [ ] Some jobs might fail during the latest successful pipeline; we should **not** resolve vulnerabilities corresponding to those in the failed scan jobs. **Non-functional** - [ ] Metrics are available to track how many unique vulnerabilities are automatically resolved.  _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._   *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.*

epic