Product discovery for first-class vulnerabilities
Follow-up of this thread: https://gitlab.com/gitlab-org/gitlab-ee/issues/7091#note_111689476
We already have vulnerabilities reported by our Security Products. They live in the Merge Request widget, in the pipeline, in the project Security Dashboard, and the Group Security Dashboard. Nevertheless, there's no way to link a vulnerability directly, and the users have to use one of the entry point listed previously. They are many advantages to consider them as 1st-class objects in GitLab:
- it's making clear that GitLab now has Security backed-in.
- Like issues and epics, vulnerabilities could be "decorated" with labels, milestones, and assignees.
- We can fix our
Severity
andPriority
matching problem by having these fields directly at the vulnerability level. - It's easier to gather data about a vulnerability, otherwise we'd have to parse the issue to retrieve what we need (like the target milestone).
- It helps to identify clearly vulnerabilities among other issues
- They can be queried and displayed directly in code
- Users would be able to create vulnerabilities directly (so they don't belong to tools output only).
- They can have different statuses, related to vulnerabilities life cycle (New, in review, confirmed, closed).
- They can have specific data (like discovery date, 1st detected date, etc.) and behavior (state machine to change state).
- It's easier to create relations between vulnerabilities. If we have duplicates (like someone is reporting something already spotted by a vulnerability), mixing vulns and issues is more complex.
- We can refer to vulnerabilities directly, because if they're 1st-class objects, they have their own URL. With the current implementation, we can use only issues, which means we must convert to be able to link.
- If it makes sense for incidents (&349), it makes sense for vulnerabilities. They can have a special view, with more metrics and data than issues (which would be super useful).
- We can have specific authorizations for Security roles.
- Vulnerabilities can have a different privacy/confidentiality policy than issues. (Private by default for ex).
- We can imagine MRs being confidential by default if they refer to a vulnerability.
- It's a lot easier to expose 1st-class objects through public APIs.
- Currently, we can convert a vulnerability to an issue if we want to investigate. But there's not link to the corresponding issue. Not only this is a process concern for users, but it's also bringing some limitations: we use a template for the issue creation. That means, if we update the template, the issues are not updated and can lack important information.
This issue is to discuss pros and cons for this new approach.
/cc @bikebilly for updating the description if needed.
Direction
We will be moving towards vulnerabilities as first-class objects as issue types cannot meet our needs and long term vision.
Ultimately, the decision was made in this statement: "Since vulnerabilities need more than just the open/close states, and since they will not appear everywhere there are issues, I don't think issue-types are a good solution." https://gitlab.com/gitlab-org/gitlab-ee/issues/8493#note_138126143