Bulk update status of vulnerabilities in Vulnerability Reports
Release Notes
It is currently possible to select and bulk dismiss multiple vulnerabilities from a Vulnerability Report. This is helpful in quickly removing redundant occurrences or false positive. However, you must still open up individual vulnerability details to change status to anything other than Dismissed. This is inefficient for doing routine activities such as resolving all vulnerabilities no longer detected by securing scanners.
This bulk actions enhancement addresses this limitation. Selecting one or more vulnerabilities from a Vulnerability Report will now present the option to set any status. You can even move vulnerabilities back to Detected if they need further triage evaluation. Combined with the filtering capabilities, it is easier than ever to isolate and take action on a specific subset of vulnerabilities all at once.
Why are we doing this work
It is currently possible to select and bulk Dismiss multiple vulnerabilities from a Vulnerability Report. This is helpful in quickly removing redundant occurrences or false positive. However, you must still open up individual vulnerability details to change status to anything other than Dismissed. This enhancement makes it possible to bulk update vulnerabilities to any status.
Relevant links
Implementation plan
-
frontend As of today, the ee/app/assets/javascripts/security_dashboard/components/selection_summary.vue
already allows the user to select multiple vulnerabilities and dismiss them. We have to extend this functionality, and allow the user to change the status of the bulk selection instead of allowing only to dismiss them. We can probably reuse the same component that will be created #285470 (closed) for changing the status. Then we'll need to create an input so that the user can specify the Reason and implement the buttons. Clicking on the button should trigger a confirm modal and we should commit the action only when the user confirms the modal. -
~~For the reason box, the backend is going to accept either comment
ordismissal_reason
as an argument. I'd personally preferdismissal_reason
more as it's more descriptive. See #292636 (comment 466673401) for more context.~~ This scope was moved to #324119 (closed)