Playing the devil’s advocate
I changed by mind because security is a “business” topic (topic is “security vulnerability”) and I see no reason to start having issue types that are business-related. With this logic, we’ll have “wcag” issue types, “localization” ones, etc. In JIRA this is better expressed as labels IMO, and I feel we should keep the issue types to the minimum and representing the type of the issue: bug, improvement, new feature, etc.
In other words, I don’t think “vulnerability” can be applied to any topic (which would make it a candidate to be an issue type) and it’s thus reserved for security issues IMO.
A security issue is a bug and falls under that type. This created an ambiguity and when creating a new issue, you’d have two ways of reporting a security issues: as a bug issue, or as a vulnerability one.
Now I understand why it’s tempting to introduce a new type (I even suggested it!). It makes it slightly easier to filter on them (not much though, since searching for the “security” label is not hard either), and, more importantly, it allows setting the “confidential” level by default. However, that works only if the reporter doesn’t use a “bug” issue type. It’s true that when the user sees “Vulnerability” in the list of issue types, he/she may be tempted to use it if a security bug is being reported.
Right now, I have the feeling that we won’t gain much by introducing the “Vulnerability” issue type and that OTOH we would add additional specific configuration to JIRA (rather than using its defaults), making it a bit more complex and harder to migrate to another issue tracker in the future.
EDIT: I’ve actually checked and it seems that GitLab doesn’t currently fully support custom issue types and that they plan to implement that in a generic “work item type” concept). See also Customizable Work Item Types (&7897) · Epics · GitLab.org · GitLab. However, they seem to plan this for the premium version only. Also, automatically setting a confidential level might be more difficult (no idea how gitlab suggests to report confidential issues).
- If we consider that security issues are very important (more important than any other of other business domains), we could decide to highlight it as an exceptional case and thus have an issue type for it.
- Users are more tempted to use the “Vulnerability” type when reporting security issues and thus we can automatically set the “confidential” status.
I’m voting +1 for solution A at the moment but I’m not strongly against solution B if the majority of committers are for it.