Jira tickets for security issues

Development
,
#1

Hi everyone,

I’m opening this vote so that we can reach a conclusion on how to create security ticket on Jira. We use to have recently a single way of doing it through Bug tickets marked as confidential and with a security label, but with the bug bounty program @vmassol performed some changes to create the Security ticket type in Jira and created the following proposal to use it: Using the Security issue type in JIRA

TL;DR in the end Vincent changed his mind in the proposal above, while I personally think it’s a good idea to now use this new Security type.

So this vote is about choosing how we will store security vulnerabilities in the future, depending on the chosen solution we will transform existing tickets to a type or to another.

Solution A: Use the old way with a Bug type marked Confidential and with security label

Solution B: Use the new way with a Security type

The vote is opened for two weeks until Wednesday 21st of December.
Here’s my +1 for solution B.

#2

I’m fine with both.

#3

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 :slight_smile: (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).

Pro arguments

  • 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.

Conclusion

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.

Thanks

#4

Pro security issue type:

  • Security issues are special in the sense that they aren’t public but that they have been fixed should be announced to make it clear that updating is important. Having a special issue type makes them more visible for release managers.
  • Security issues are important also in general in the sense that we shouldn’t have any open security issues as this endangers the safety of XWiki instances (vs. just being a limitation/annoyance in the case of most regular bugs).

Overall, I’m not convinced that this new security/vulnerability issue type is really needed and we cannot achieve the same without it, so I’m fine with both.

#5

I’m going to close this vote now as I completely forgot to do it before, but the result is ambiguous (see below), so we probably need to redo it again, maybe with a discussion on it first.

I’m counting 3 +1 for A (Michael and Thomas said they’re ok for both) and 1 +0 (I myself didn’t expressed that I was against it but it didn’t had my preference).
And I’m counting 3 +1 for B (same as above for Thomas and Michael) and 1 +0 (Vincent said he wouldn’t be against it)