Request for Assistance in Jira Automation – Vulnerability Sync Logic for CVEs

[Abhimanyu Guleria]

I'm setting up an automated rule in Jira to sync and track security vulnerabilities (CVEs) reported from GitHub via Dependabot. This is part of ensuring all CVEs remain visible and tracked until they're actually resolved.

The automation is mostly in place, but I'm facing issues with Steps 2 and 3 in the automation logic.

Current Setup:

• Trigger: Scheduled every day at 6 PM.

• JQL Condition: Filters for issues in the ACC project that are Closed and have the label github-vulnerability_dependabot.

• Then: Create a new ticket under "Security Vulnerabilities".

• And: Link the new ticket to the previous closed work item.

❗Problems Encountered:

3. Lookup step limitation:
I want to check if the same CVE is still being flagged in GitHub. The idea is to avoid reopening/resurfacing CVEs that are no longer valid.
However, Jira doesn't have access to updated CVE status from GitHub unless GitHub sends the updated status, and the "lookup issues" component isn't functioning properly—likely because the context (Work item) isn't produced earlier in the flow.

4. Validation before new issue creation:
We need a reliable way to compare the closed Jira ticket (with a given CVE ID) against GitHub’s latest open vulnerability list.
If the CVE still exists, only then should we create a new Jira ticket or reopen the previous one.

Could you help with how this cross-check (CVE still open?) can be added reliably to the automation logic before step 4 (issue creation)?

[Dick · Accepted solution]

Hi @Abhimanyu Guleria Welcome to the Atlassian Community

You should store the CVE alphanumeric code in a separate (custom) text field called CVE. The scheduled script should not only check your generated label, but also compare the CVE found against your CVE field. You can lookup these tickets, based on:

• label = yourLabel
• CVE field = Current external CVE under investigation

If the resulting array has zero length, you need to make another ticket. If the array has a length >0, then you should find out if the CVE under investigation is still active and requires another (related, so linked-) ticket to be re-opened. 

In other words: to be able to create an extra condition, you need to have more fields and critical values at your disposal.  

Kind regards,
Dick

[binay_yadav]

Hi @Dick 

Thank you for your suggestion!

I had a quick follow-up question — what if I want to verify whether a vulnerability still exists under the Security section, but the previously linked work item is already closed? In that case, I’d need to create a new work item and link it to the existing vulnerability.

How can I go about doing that? I couldn’t find an option to filter or search vulnerabilities in order to compare or re-link them.

[Dick]

Hi @binay_yadav 

Then you have an extra condition using status is Done in the lookupIssues jql. If it is, you want to find its key, then create another issue and use the linked issues selector, set that to relates to, and fill in the issue field to that exact key.

Kind regards,
Dick

[binay_yadav]

Hey @Dick Thanks for helping with the request. But the issue on my side is how to do a comparison on the external CVE to check if it is still open. I don't seem to find any JQL that can do it. Can you share a sample JQL if you have any ? 

• CVE field = Current external CVE under investigation

[Dick]

Hi @binay_yadav 

There's a string comparison operator called match, 

so you want to compare the content of your CVE field with the external CVE string similar to this:

{{#if(issue.customfield_xyz.match(".*(CVE-abc).*")}}   would match with CVE-abc

you can replace the CVE-abc value with a smart value {{testCVE}} that has it's content defined from your interaction with the CVE-site.

More information on smart values and match by Atlassian 

Kind regards,
Dick

[Bill Sheboy]

Hi @binay_yadav and @Dick 

To use a dynamic regular expression with the match() function, that expression must first be stored in a created variable.  This will help the expression fully evaluate before it is attempted, preventing timing and syntax problems.

For example:

• action: create variable
  • name: varRegEx
  • value:

.*({{testCVE}}).*

• action: something which uses the match()

{{issue.customfield_12345.match(varRegEx)}}

Please note well: if the variable testCVE could include reserved characters for a regular expression, additional logic is needed to escape them before use in the match() function.

Kind regards,
Bill