Spike: Investigate usage of WorkItems for vulnerabilities
Problem
Our vulnerability report architecture is slowing down our velocity when it comes to providing new features and abilities for our customers to consume our vulnerability data. Adding new features almost always will require us to extend database tables or add indexes. This requires lots of back and forth between various teams as each new feature may impact performance.
Currently we can only filter on:
- Status
- Severity
- Tool
- Activity
For grouping, we can only group by all of the above plus OWASP Top 10 2017. Adding new grouping types appears to require new database columns meaning it's rather rigid in how we are able to extend this.
(TODO: If someone else could chime in with more details on how hard it is to add in new features or give examples of timelines of how long it takes, please do so)
Goal
The goal of this issue is to investigate looking at using WorkItems for vulnerability data instead of storing vulnerabilities in a custom vulnerability table.
Traditionally, we have considered vulnerabilities as completely separate entities. One could argue that vulnerabilities should be treated no differently than any other item of work. As an example, vulnerabilities found by GitLab tooling:
- Relate to code or environments that GitLab users' manage or monitor
- Can have a status (Open, Closed, Being Remediated)
- Need to be commented on or assigned to people or groups to remediate
- Should be customizable with labels
- May require sub-tasks for proper remediation or investigation
What we would gain
By using WorkItems, all of the above become immediately available by using either built in WorkItem properties, or by applying custom internal labels. Even adding new filtering or grouping could be done by simply applying custom labels. We could also support things such as monorepos, by applying internal labels of directory paths, customers could filter out or create custom reports of vulnerabilities that affected a certain path.
Proof of Concept Plan
We should take a single analyzer such as semgrep, and wrap it in custom logic that instead of outputting a gl-sast-report.json will take the report output and call the GitLab API to generate a workitem per vulnerability. Additionally, custom boards will be created to demonstrate how well this feature could work for creating custom views or boards.
If successful, it maybe worth investigating extending the WorkItem objects to support more devopssecure specific things (such as ticket widgets or custom views).
Challenges
- Performance of WorkItems for large numbers of issues across groups is an unknown.
- How to handle automatic vulnerability resolution.
- How to retroactively update WorkItems if vulnerability information changes