Jira automation to close issue when vulnerability is closed?

[Mike Tocci]

We have integrated Snyk into the new Jira Security feature. Now Snyk alerts flow in, and we have an automation to create an issue when a vulnerability is found. So far so good.

Now we see that vulnerabilities are being closed automatically by Snyk as we remediate issues, and this closed status is being detected by the Jira issue in the Security field on the right side (see screenshot).

My question: is there a way to access this new Security field so that I can automatically close this issue?

[Bill Sheboy · Accepted solution]

Hi @Mike Tocci 

I suspect the answer depends on how that new field/information from the marketplace addon is populated.  And in my experience, a field dynamically updated from the addon may not be directly accessible by rules until it changes...and even then, it must be captured in a created variable to use it.

First thing, to learn if it has a custom field provided to rules please use the how-to article linked below.  Essentially you would identify an issue with the field, and then call the REST API with a browser, and then search for your field.  If you see the field, it may be supported.  https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/

Next, check the marketplace vendor's documentation on how to use their product with automation rules.  It may be possible to use a webhook triggered rule to detect the field change and then make your issue transition.

Kind regards,
Bill

[Mike Tocci]

Hey @Bill Sheboy I did use the api to get the full json structure of an issue, and I see that the security field does not exist. So it looks like we do not have access to this data. Hope they roll out more automations for the security feature 🤞

[Bill Sheboy]

A possible work-around might be...dynamic fields (without a custom field) can sometimes be saved in a created variable (or other field) and then used in the rule.  So try this, triggering the rule from an issue which has that field:

• trigger: manual
• action: create variable
  • name: varSecurity
  • value: {{issue.Security}}
• action: write the variable to the audit log, {{varSecurity}}

If you see a value in the log, you could try another trigger to start the rule and then use it for your scenario.  If you do not see the value, it is not available.

[Mike Tocci]

Hey @Bill Sheboy I would try that but the json structure of the ticket shows that there is nothing like issue.security to create a trigger on. I think this is totally outside the ticket data. Thanks!

[Bill Sheboy]

I do not believe the dynamically generated fields show in the issue search JSON (from the REST API), even though they may be accessible to the issue.  Perhaps try a quick test and just write it to the audit log to learn if that is the case.

[Mike Tocci]

Thanks @Bill Sheboy I tried your work around and it didn't work. So we'll look for additional automations as they roll out from Atlassian.

[Tim Costa]

You can now finally, they don't document it well but this is what I do: 

Set up an automation to run every 12 hours (or whatever you see fit)  to look for the JQL below. 

statusCategory != Done AND vulnerability[status] = CLOSED ORDER BY due ASC, created DESC

The key is   vulnerability[status] = CLOSED


Once it finds those issues create a Branch for each issue then transition the issue to whatever "Done" status you choose. 


This just started working for us a few months ago. 

Good luck.\

[Ryan Pettaway]

Hey @Mike Tocci 

Sorry, this isnt an answer more of a question, is your Security field custom or part of an addon? I'm curious how you're getting this mapped and changed dynamically. I'm sure many of us would love to have this exact sort of feature to automatically close vulnerability related issues when the vulnerability itself has been closed from its source.

[Jose Lomeli]

Hi @Mike Tocci , this was released recently:

JQL vulnerability search | Jira Software Cloud | Atlassian Support

You can create an automation rule using this to automatically close tickets :)

[Tim Costa]

@Mike Tocci 
I know this may be late, and maybe you already figured this out. 

You can set up an automation using smart values to run nightly and find any vulnerabilities that are currently "closed' per Snyk and then close the associated issue. 

If you want more info let me know!

[Jose Lomeli]

Hi @Tim Costa , can you explain this with more detail, as far I know, there is no way to get the vulnerability status linked to a ticket

[Tim Costa]

I can't believe I didn't explain this, I am so sorry. 

They don't document it well but this is what I do: 

Set up an automation to run every 12 hours (or whatever you see fit)  to look for the JQL below. 

statusCategory != Done AND vulnerability[status] = CLOSED ORDER BY due ASC, created DESC

The key is   vulnerability[status] = CLOSED


Once it finds those issues create a Branch for each issue then transition the issue to whatever "Done" status you choose. 


This just started working for us a few months ago. 

Good luck.

[Jose Lomeli]

For everyone interested in this topic, vote in the following ticket: https://jira.atlassian.com/browse/JRACLOUD-82039, it's one of the solutions that would make possible auto-closing issues and other useful tasks!

[Evgenii]

Hi, @Mike Tocci 

Haven't worked with Snyk, but I suppose, that if you can search for such issues, with closed vulnerabilities, by JQL, you can make rule, that will run by schedule. It will look for not closed issues with closed vulnerabilities and close them.

[박 범수]

It seems impossible to scan for vulnerabilities through JQL. 

https://jira.atlassian.com/browse/JRACLOUD-82039