<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, 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. --> ### Release notes It is currently possible to select and bulk change status of multiple vulnerabilities from a Vulnerability Report. Furthermore, there is no way to choose a dismissal reason nor leave a comment when bulk dismissing. This prevents other users on the security team from knowing exactly why a particular item was dismissed. Bulk actions addresses both of these limitations and more. Selecting one or more vulnerabilities from a Project Dashboard or the Vulnerability Report in a Group or the Security Center will now present the option to set a dismissal reason, leave a comment, attach to an existing vulnerability, or create a new vulnerability with all selected vulnerabilities attached to it. You can even move vulnerabilities back to Needs triage if they need further triage evaluation. And in case you accidentally make the wrong change, the post-submit toast notification now has a link to undo the most recent change. https://docs.gitlab.com/ee/user/application_security/vulnerability_report/ ### Problem to solve The current vulnerability report experience is not optimized for users who want to quickly change the dismissal reason for a set of vulnerabilities that share a similar attribute or resulting status. Engineering DRIs - ~backend @Quintasan - ~frontend @lorenzvanherwaarden ## Scope | FE | BE | Note | |----|----|------| | https://gitlab.com/gitlab-org/gitlab/-/issues/408366+s | https://gitlab.com/gitlab-org/gitlab/-/issues/408744+s | %"16.0" | | https://gitlab.com/gitlab-org/gitlab/-/issues/408909+s |https://gitlab.com/gitlab-org/gitlab/-/issues/411774+s|%16.1| | - | https://gitlab.com/groups/gitlab-org/-/epics/10674+ | %16.2 | | https://gitlab.com/gitlab-org/gitlab/-/issues/408909+s | https://gitlab.com/gitlab-org/gitlab/-/issues/412667+s | %16.3 | | - | https://gitlab.com/gitlab-org/gitlab/-/issues/416377+s | %16.3 | | https://gitlab.com/gitlab-org/gitlab/-/issues/410606+s | - | %16.3 | | https://gitlab.com/gitlab-org/gitlab/-/issues/408983+s ~Stretch | https://gitlab.com/gitlab-org/gitlab/-/issues/411570+s | %16.3 | | https://gitlab.com/gitlab-org/gitlab/-/issues/420065+s | https://gitlab.com/gitlab-org/gitlab/-/issues/420064+s | | ### Proposal Allow users to change the dismissal reason on a set of vulnerabilities at the same time. ### Related design issues - [Design: Enhanced bulk actions](https://gitlab.com/gitlab-org/gitlab/-/issues/267582/ "Design: Enhanced bulk actions") - [Design: Bulk select all across pages](https://gitlab.com/gitlab-org/gitlab/-/issues/350226/ "Design: Bulk select all across pages")   #### MVC Users will be able to: - Select a dismissal type - Acceptable risk - False positive - Mitigating control - Not applicable - Used in tests ##### Requirements * Store the dismissal reason (e.g. False Positive) for all vulnerabilities when bulk dismissed * Store any comment ("Reason for status change...") made with any bulk status change * Record the user who made the bulk change * Record the time of the bulk change * Any change appears on each affected vulnerability's details page along with who made the change and when. This is the same as current behavior when manually updating a single vulnerability's status (see example below). ### Permissions and Security Anyone with permissions to view and modify vulnerability records can use this new behavior. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change * Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements * If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html --> ### 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 --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> _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._ <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->