Explore 1:many, many:1, many:many relationships for Vulnerabilities and Issues/Epics
Problem to solve
Currently, a single Finding (vulnerability occurrence) can only be promoted to a new Vulnerability. But other similar Findings should become occurrences of the same Vulnerability, not separate or unique Vulnerabilities.
Similarly, there will be times when multiple Vulnerabilities are all resolved by the same remediation Issue (e.g. "upgrade Rails version"). To prevent duplicate issue creation and also provide more visibility into Vulnerability resolution in these cases, we need to allow linking many Vulnerabilities to the same Issue.
It is also possible, though less likely, that more than one issue is opened to address a vulnerability. This may be the case where the resolution of a particular defect requires more than one major code or component change. For instance, properly fixing something might necessitate front end and backend changes, each of which could be tracked by a separate issue against the same vulnerability. However, this could introduce complexities elsewhere in the workflow and should be verified as a legitimate use case first.
many_to_many has_one has_many
Intended users
Further details
- For the MVC of Standalone Vulnerability objects, it was decided that it's enough to have a
1 <-> 1
relationship between Vulnerabilities and Findings. The next step is to have1 <-> *
relationship between them - the entire engineering discovery
- the MVC backstage implementation issue
Proposal
Add functionality to associate or deassociate a Finding to/from existing Vulnerability
TODO:
- the behavior of the Finding's
state
upon attaching/detaching it to/from a Vulnerability
Permissions and Security
Additional ability update_vulnerability
will be added for developer
and auditor
roles to EE::ProjectPolicy
Documentation
Add docs on API operations "Attach to a Vulnerability" and "Detach from Vulnerability" to the Vulnerabilities standalone resource API doc page
Testing
TODO:
What does success look like, and how can we measure that?
Success: security analysts are able to attach new occurrences of already created Vulnerabilities to them Measure: the number of Findings in default branch with the same name that some other Finding has but not attached to any Vulnerability (the lower is better)