Dismiss vulnerability or create an issue in security reports
Description
We have several security features, and those features create reports for vulnerabilities.
Sometimes there are false positives that create noise in the report. It would be useful to implement a way to dismiss them and save this feedback for later use in signal-to-noise.
If the problem is real, an issue can be created from there to implement a solution.
Proposal
We want the users to have "Dismiss" buttons and record the result in the DB. This will allow us, in future iterations, to suggest a "score" based on such collected statistics. The score could influence the issue rank, and would nuance the data reported by our tools. As @gonzoyumo said, we should gather more data from the user, and understand why the issue has been dismissed. We just want to know it has been dismissed, whatever the reason.
We could also have a button to directly open an issue with the corresponding security alerts. If we are able to link an issue with its resolution (a commit), then it would be valuable for the users as well.
Design
Scope
In scope:
- Create new issue
- Dismiss/Undismiss vulnerability
- Dismissed vulnerabilities are strikethrough and ordered at the bottom of the list
- Open modal
- Information => See mockups
- Project scoped (dismissed vulnerabilities are dismissed for the whole project)
- Vulnerabilities can be dismissed from all branches
- Masters and developers are able to dismiss vulnerabilities
Out of scope:
- Reason for dismissal
- We cannot create double issues from vulnerabilities (changes create issue button to go to issue button after issue has already been created)
- When user creates an issue he should not be able to dismiss and vice-versa
- Better mobile support (as we are using modals)
- Hide full path of "file" on item in merge request widget and pipeline detail view. That information will be visible in the modal image
Flows
Dismissal:
- User sees vulnerability
- User clicks vulnerability title/anchor
- Modal opens
- User dismisses vulnerability
- Modal auto closes
- The vulnerability is dismissed
- Gets
strikethroughstyling - Gets reordered to the bottom of the vulnerabilities list
- The user who dismissed the vulnerability gets recorded and is displayed in the modal, including the pipeline from which it happened (only shown when opening the vulnerability again
- No confirmation message is shown of any kind (keeping it simple and quick)
New issue:
- User sees vulnerability
- User clicks vulnerability title/anchor
- Modal opens
- The user creates a new issue
- Page changes to new issue creation screen with title and description pre-populated.
- User clicks create
- Issue is created
- The user is on the new issue page
Reverting dismissal of vulnerability:
- User sees dismissed vulnerability
- User clicks vulnerability title/anchor
- Modal opens
- User reverts dismissal of vulnerability
- Modal auto closes
- The vulnerability is undismissed
- Undoes
strikethroughstyling - Gets reordered to the normal position in the vulnerabilities list
- The user who dismissed the vulnerability gets deleted. The vulnerability is back as is
- No confirmation message is shown of any kind (keeping it simple and quick)
Dismissal/undissal failure:
- User dismisses/undismisses vulnerability
- Modal does not auto close
- The vulnerability is not dismissed/undismissed
- Modal gets an additional inline error message stating that the user should try again:
Mockups
Undismissed vulnerability modal:
- Instances box within the modal has a max height and becomes scrollable if it has many items (160 or 240 px max height)
- Hide items that are not available to some tests
- Learn more links towards documentation (cc: @axil can you provide the link?)
- Create issue button will pre-fill the issue description and title with the contents of the vulnerability
Title:
Investigate vulnerability: VULNERABILITY TITLE
Description:
The following vulnerability from PIPELINE should be addressed:
- Description: Long text, could be a simple text for now and maybe later improved to be markdown with code formatting. We should be careful on the rendering of this value that can hold new lines.
- File: link to repo's file with start + end line (or just start line)
- Identifier(s): comma separated list of identifiers and potentially linking to external DB (CVE, CWE, etc.)
- Severity: Short text (usually one of: Critical, High, Medium, Low, Unknown)
- Solution: Long text, could be a simple text for now and maybe later improved to be markdown with code formatting. We should be careful on the rendering of this value that can hold new lines.
- Confidence Level: Short text (usually one of High, Medium, Low, Unknown)
- Source(s): a List of URLs pointing to external sources of the vulnerability
- DAST modal specifics
before | after |
---|---|
- Error specifics:
Merge request widget and pipeline security tab:
- Title becomes clickable
- Mockup for each report since they are all different?
before | After |
---|---|