<!--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 With this release you can now bulk add a vulnerability to new or existing _GitLab_ issues. 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 bulk attach vulnerabilities to issues. ##### Requirements Users will be able to: - Select a vulnerability(s) - Bulk attach a vulnerability to an _existing_ issue - Bulk attach to a vulnerability to a _new_ issue - **\[out of scope\]** Bulk attach a vulnerability to an _existing_ Jira issue - Covered in https://gitlab.com/groups/gitlab-org/-/epics/17856+ - Bulk attachment will have a limit of 100. This was decided as we can only see 100 max vulnerabilities in report page and this will save us from performance hit as well. - The new issue created for more than 1 vulnerability will look like: (See https://gitlab.com/groups/gitlab-org/-/epics/13216#note_2291891226) - Title: `Issue created _from_ vulnerabilities` - Description: This will be blank - In the body there will be a pane for associated vulnerabilities For detailed design: https://gitlab.com/gitlab-org/gitlab/-/issues/451534/ This will be done in iterations: * 1st iteration: Bulk attach a vulnerability to an _existing_ issue: The required ~backend work is already there and we can release this in the first iteration after finishing the ~frontend work. * 2nd iteration: Bulk attach to a vulnerability to a _new_ issue: ~backend and ~frontend both needed. Issues are added in this epic. In the second iteration, we can release this. * 3rd iteration: Bulk attach a vulnerability to an _existing_ Jira issue: It will require more work (new service needed for bulk attachment) compare to other two mentioned, I added the issues that will be required to be done for this. This can be released in third round. * Jira issue scope captured in https://gitlab.com/groups/gitlab-org/-/epics/17856+ Additional requirements: * 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). _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-->