+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