Draft: Use dismissal feedback on vulnerability page
What does this MR do?
This MR's goal is to bring the dismissal reasons from the security dashboard ([No reason], Won't fix / accept risk, False positive) to the vulnerability details page. This is intended to be a small, incremental improvement. The issue A history should be kept of vulnerability state changes and their reasons is a proposal for a more robust solution to capturing reasons for vulnerability state changes. This MR does, however, try to implement the vulnerability state-change reason for the dismissal state in a generic way so that it might make it easier to add reasons for other (all) state changes.
This MR will help us be able to collect more accurate false positive rates of our analyzers, as discussed in the issue How to (safely) move to a metrics based decision group. We currently can't collect accurate metrics on false positive rates because users aren't able/required to specify a dismissal reason in all locations where vulnerabilities can be dismissed.
This MR:
- Moves the dismissal reason strings to
ee/app/assets/javascripts/vulnerabilities/constants.js - Uses the dismissal reasons on the vulnerability details page to show the current dismissal reason
Still left to do:
-
Should probably pull the dismissal feedback sub-list on the vulnerability details page into its own vue component -
Use the selected dismissal feedback when dismissing a vulnerability from the vulnerability details page -
Tests
Screenshots
 |
|---|
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team