Using the Security issue type in JIRA

Development
#1

Hi devs,

WDYT about aligning all our security issues in jira by doing the following:

  • Decide that new security issue must be created using the new Security issue type. Note that when doing so, the confidential level is set automatically which makes it better to avoid sending a jira notification on a public channel by error.
  • Drop the security label since the issue type would be enough to identify security issues.
  • Move all existing security issues to use the new Security type (no email sent during the conversion ;)). Also remove the security label.
  • Update documentation to explain this new way of creating security issues
  • Update existing security filters on jira

Thanks

1 Like
Jira tickets for security issues
#2

Indeed, did not notice this new type, +1 for me.

#3

I’ve introduced it recently (discussed only on chats) for the intigriti bug bounty so that the intigriti software could automatically security issues in jira.xwiki.org that have the confidential level set.

The idea of this proposal is to generalize it.

#4

+1

Thanks,
Marius

#5

+1

thanks

#6

+1

Thanks,
Alex

#7

I’m not sure regarding the benefits of this proposal. I’ve just tried creating a security issue and I cannot see how selecting the issue type automatically sets the confidentiality level - is this magically changed after the creation? In the form I’m still seeing “Security Level” “None” even after selecting the “Security” issue type:

2022-11-04-Create Issue - XWiki.org JIRA

If this is something magic that happens after saving the issue with the type, I’m wondering:

  • How would this affect existing issues?
  • Can we still disclose security issues?

If there is nothing magic, I’m wondering if this issue type won’t have the opposite effect, i.e., making it more likely to forget setting the confidentiality level as you already set the issue type to “security”. Also, having more issue types might make it more difficult to move to a JIRA alternative where using labels is much more likely to work than a separate issue type.

#8

yes, through a post workflow step.

#9

It won’t since existing security issues already have the confidential level set.

#10

yes, by removing the confidential level

#11

But what about security issues that have already been disclosed? Would converting them change them to confidential again?

#12

@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 :wink:

#13

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.

#14

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.

#15

What’s the use case for this? How can we reveal security issues without having them fixed?

#16

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.

#17

FWIW, I’ve now set issue.issueType.name == 'Security' && issue.resolution == null.

#18

I don’t think they were confidential in the first place and there wasn’t anybody who cared enough to change them later.

#19

ok so making them confidential would be the right move I guess :slight_smile:

#20

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?