yes, by removing the confidential level
But what about security issues that have already been disclosed? Would converting them change them to confidential again?
@MichaelHamann Note that right now we have a Security issue type and we need one to make it work for Intigriti, so right now we have 2 ways to represent a security issue and that’s not great. Hence this proposal.
I see more pros than cons.
Re migration to another issue tracker, there’ll be the need to perform a LOT of changes and that’s a small one compared to the rest so I would only count it as a small cons. Also only using what other issue trackers support is not a great idea IMO since it means not benefitting from the best feature and hampering ourselves. But it’s a valid point 
That’s easy to solve. Right now in the workflow step I’ve used only 1 condition (issue.issueType.name == 'Security') but it’s easy to add the resolution too for example so that if it’s resolved then we don’t set the confidential status.
Note that we have existing security issues that are neither resolved nor confidential, for example Loading....
Regarding Intigriti, I’m wondering if you couldn’t have created a workflow that just sets all issues created by the Intigriti user to be confidential instead of introducing a new issue type.
Anyways, I don’t care enough as long as you take care that we don’t mess up existing issues, my vote is 0 on this.
What’s the use case for this? How can we reveal security issues without having them fixed?
Indeed that could work too but again I see more benefits, including the fact that it’s easy to forget to set the confidential level.
FWIW, I’ve now set issue.issueType.name == 'Security' && issue.resolution == null.
I don’t think they were confidential in the first place and there wasn’t anybody who cared enough to change them later.
ok so making them confidential would be the right move I guess 
I’m still hesitating since an issue type is indeed cross topic and should not be a domain ideally. For example, by using a Security type, we cannot differentiate anymore between a Security bug or a Security improvement.
It’s true that it makes it simpler to not forget to set the confidential level but is that enough to move to a Security issue type… I agree with Michael that for Intigriti we could change the workflow to be based on the reporter.
So, right now I’m more tempted to cancel this proposal and to work to remove the Security issue type.
WDYT?
+1
If possible, you could also add a workflow that automatically marks issues with the security label or any of the attacker_ or attack_-labels as confidential to make it less likely that we create non-confidential security issues.
I could but we almost never add these labels when creating the issue. And users certainly don’t do that.
This could be solved by renaming the new type “Vulnerability”: it’s a bug that concerns security. For me this type should be only about that. We should still use the label security when an improvment is about improving security or when a new feature is about security (e.g. 2 FA)
If we do this only for intigriti I agree it doesn’t worth keeping it. Now I do like the idea of ease life of external reports to create tickets related to a security vulnerability and to ensure they don’t forget to set the confidentiality level.
Also I believe it will ease our life to keep track of them as the filters will be easier to maintain. And finally I also think we could on the long term have maybe some better creation template for this specific type to help setting right away important information. But that could be done later.
So all in all I’d be in favor of keeping the new type and moving our existing issues to this type.
I actually have another argument for using the Security type: it allows a nice immediate view when using some jira dashboard to quickly view the number of security bugs / fixes in a release.
Yes but that’s a bad argument IMO. What about immediately viewing WCAG issues for example? or Usability ones? or …
It makes no sense to me that security would be at the same level as bug or improvement or new feature or task since a security issue can be any of these.
Again for me here the type is refers as “Vulnerability”. So no, it’s not a security improvment, it flags a vulnerability and it’s good if it catches admin eyes to spot immediately “ok there was XX vulnerabilities fixed there”.
“Vulnerability” is a bit better but in the end it’s the same for me. A vulnerability is a bug.
As for catching admin eyes, we can have a gadget on our jira dashboard for security issues, that’s easy to do. Same in RN
Hi there,
I’m reviving this proposal since we never reach an agreement, and we’re having question about the two types (see: Even remote code executions of type "Bug" instead of type "Security" on jira.xwiki.org)
I was about to suggest to just get rid of the security type since we just don’t use it anymore since 2 years now. But first I want a confirmation: @vmassol do you recall the technical limitation that forced you to create that? It was to ensure to have tickets created automatically with the confidential level properly set, right?
I’m asking because we might have again in the future the same need: i.e. we might ask again for a security bug bounty program, in which case we’d need to set it up once more. So I’m hesitating, again. wdyt?
Yes, by having a type, I was able to set up a workflow for it that was setting the level property to confidential.
This is how I did it:
FYI the way I did it is by editing the xwiki workflow and creating a post function for the create step, then I’ve used a scriptrunner function for setting the security level if the issue type is “security”
Can be seen on these screenshots:
Yes, we might need it. Now, one another way could be to do the same but based on the reporter name and if it’s " Intigriti Integration", set the confidential level. I haven’t tried it but it would be easy to try. We would also need to update the intigriti config so that “bug” issues are created and no longe “Security” ones but that’s easy too.
Thx