Turn new Snyk security alerts into triaged Jira tickets

Watch our Snyk organization and run every time a new security issue appears, using the Snyk poll trigger for new issues. I want vulnerabilities triaged into Jira automatically instead of sitting in a dashboard nobody opens.

When an issue fires, pull the full detail with Snyk's "Get issues by org ID" so you have the vulnerability identifier (the CVE where one exists), the severity, the affected package and version, and the fix version if Snyk lists one. Then call Snyk's "Get project by project ID" for the project the issue belongs to, so you know which repository or scan target is actually affected.

Before creating anything, build a stable dedupe key from the vulnerability identifier plus the affected package name, for example "CVE-2025-1234|lodash". Search Jira using "Search Issues (JQL)" for an existing ticket carrying that key, looking across every Jira project we route security work into and across all statuses including closed ones. Whenever you create a ticket, always write the dedupe key into the summary or description so this lookup keeps working on future runs. This dedupe step is the most important part of the workflow.

If no matching ticket exists and the severity is critical or high, create a ticket with Jira's "Create Issue". The ticket must contain the CVE or vulnerability identifier, the affected package and its current version, the fix version if one is available (say clearly when there is no fix yet), a link back to the Snyk issue, the dedupe key, and a plain-language explanation of the actual risk: what an attacker could realistically do with it and whether it looks reachable in how we use the package. Do not paste a raw scanner dump, write something a developer can act on without opening Snyk.

Route the ticket to the Jira project that owns the affected repository, deriving the repository from the Snyk project name. Keep this as a simple, editable mapping of repository to Jira project, and fall back to a default security project whenever nothing matches so no finding is ever dropped. Map Snyk severity onto Jira priority: critical becomes Highest and high becomes High.

After the ticket is created, post to our security channel with Slack's "Send a Message". Keep it to a few lines: severity, the affected package, one sentence on what the risk is, and links to both the Snyk issue and the newly created Jira ticket.

If a matching ticket already exists, do not open a second one. Post a short Slack note saying the issue resurfaced, linking the existing ticket. If that existing ticket is already closed, call this out explicitly, because it means something we previously fixed has come back.

Ignore medium, low and informational severity issues entirely: no ticket and no Slack message, so the security channel stays signal only.