Is it possible to get the Github repository name from Jira Automation for "Vulnerability found" rule

[Bo Roth]

I'm wanting to be able to put the github repository (Security Container) into the Ticket title, and to label & route tickets accordingly based on the github repository that they came from. I'm not seeing anything in the documentation where I can get the repository name, does anyone know of a way to get it? https://support.atlassian.com/cloud-automation/docs/jira-smart-values-security/

Alternatively, I'm looking at forking the https://github.com/reload/github-security-jira to try and add additional options/parameters for my needs, but then will also be trying to link the newly created ticket to the Vulnerability in Jira.

Does anyone know of any other better-supported Automations or 3rd-party tools to help with this?

[Jorge Cammarota]

Today, no. The "Vulnerability found" trigger in Jira Automation, using the Security integration (including GitHub Advanced Security), does not expose the repository name as a smart value. The available smart values are exactly as listed on the page you sent and do not include container, repo, or org.

According to the official security smart values documentation, only the following exist:

• {{vulnerability.displayName}}

• {{vulnerability.description}} (and its .text, .wiki, .html variants)

• {{vulnerability.type}}

• {{vulnerability.introducedDate}}

• {{vulnerability.lastUpdatedDate}}

• {{vulnerability.severity}}

• {{vulnerability.identifiers}}

• {{vulnerability.additionalInfoContent}}

• {{vulnerability.additionalInfoURL}}

• {{vulnerability.status}}

• {{vulnerability.url}}

None of these explicitly return the "security container" (GitHub repository) or the GitHub organization. In some cases, the repository might appear:

• In {{vulnerability.displayName}} (if the provider includes it in the name); or

• In {{vulnerability.additionalInfoContent}} (e.g., filename + path, which sometimes contains part of the repo).

However, this is just free-form text, not a structured field you can reliably use for routing.

What This Means for Your Goals

1. Putting the repo name in the summary automatically
With native Automation, you can only:

• Use the fields above directly; or

• Attempt textual parsing (regex) on {{vulnerability.description}} or {{vulnerability.additionalInfoContent}}, if you are certain the GitHub text format always includes the repository in a predictable pattern (e.g., if additionalInfoContent contains something like org/repo/path/to/file). This is fragile and entirely dependent on how GitHub formats this data.

2. Labeling and routing by repository
Same limitation: without a dedicated repoName, securityContainer, or similar field, you cannot create robust rules like "if repo == X then assign to Y." You can only:

• Filter/route by severity ({{vulnerability.severity}}),

• Type ({{vulnerability.type}}),

• Or by specific text patterns in description / additionalInfoContent.

Regarding Alternatives / Apps / External Scripts

The idea you mentioned of forking a project like reload/github-security-jira is a coherent path if you want this level of control because:

• There, you control the payload coming from GitHub.

• You can add custom fields (e.g., "Repository Name," "Organization," "Security Container ID").

• You can populate these fields in the created Jira issue (summary, labels, custom fields) as needed.

This also addresses your other point:

• "Trying to link the newly created ticket to the vulnerability in Jira"
  With an intermediate service (like an extended version of github-security-jira), you can:

  • Store the GitHub vulnerability ID,

  • Include a direct link ({{vulnerability.url}} currently only points to the security tool),

  • Or even synchronize status between both ends if you write that logic.

To date, there is no "more official" tool in Atlassian's documentation that exposes the repository name as a smart value within the "Vulnerability found" trigger. The supported integrations (including "GitHub Advanced Security with Jira") consolidate data into security containers linked to the Jira Space, but this is a configuration-level concept, not something Automation exposes as a variable.

Practical Paths You Can Take

1. Confirm the limits of native Automation.
* Rely on the smart values documentation: Atlassian Support: Automation smart values - security
* If it's not on the list, it's not available for use in rules today.

2. "Text parsing" workaround (if the GitHub format is stable).
* View a real vulnerability payload in Jira (use a "Log action" with {{vulnerability.description}} and {{vulnerability.additionalInfoContent}}).
* If the repository always follows a clear pattern, use:
* "Text contains" conditions for simple labels; or
* As a last resort, a "Send web request" to your own service that parses the text and returns the repository name in a custom field (then use a second "Issue updated" trigger to react).

3. Move to a custom integration (like a fork of github-security-jira).
* Have the external app create the issues instead of relying on the "Vulnerability found" trigger.
* In this app, populate:
* Summary with "[<repo>] <title>";
* Labels like repo-<name>;
* Custom fields like "GitHub Repository," "Organization," "Alert URL," etc.
* Afterwards, use standard Jira Automation (issue creation/update triggers) for any routing you want, because the repository data will already be in normal Jira fields.

4. Marketplace Apps / Third-party tools.
* As this landscape changes frequently, it's worth looking for apps specifically handling "GitHub Advanced Security" + Jira or "Security vulnerabilities" + Jira.
* However, again, for your specific requirement (repository name as a field), they often face the same limitation of Atlassian's security API – so a custom or forked app is frequently the most flexible solution.

https://support.atlassian.com/cloud-automation/docs/jira-smart-values-security/

https://github.com/reload/github-security-jira