Re-rank your Jira security backlog by real-world exploitation

Every weekday at 8am, sweep my open security backlog in Jira and re-rank it against what attackers are actually exploiting right now, using GreyNoise for the exploitation evidence and Slack for the summary.

Start with Jira's Search Issues (JQL) to pull the open vulnerability and patching tickets from my security project. Treat anything that is not in a done, closed, or resolved state as open, and let me set the project key and the exact status list at the top of the workflow so I can point this at whichever project holds my patching work.

Read each ticket's summary and description and extract the CVE identifiers it references. CVEs are often written into free text rather than a dedicated field, so look through the whole body and pick up anything matching the CVE-YEAR-NUMBER pattern. A ticket can reference more than one CVE. If a ticket references no CVE at all, skip it and leave it untouched, since there is nothing to check it against.

Collect the unique CVE identifiers across every ticket and check them against GreyNoise in a single Bulk CVE Lookup rather than one call per ticket. Where the bulk result suggests exploitation activity, or where it is ambiguous or missing the detail I need to justify a change, fall back to Retrieve CVE Information for that specific CVE to get the full timeline and the observed exploitation detail.

A ticket qualifies for escalation when its CVE is now showing active in-the-wild exploitation and the ticket is still sitting at a low or medium priority. Being theoretically severe or having a high severity score is not enough on its own. What matters is that GreyNoise is observing the vulnerability being exploited in the wild right now. Use your judgement reading the GreyNoise evidence, and when it is genuinely unclear whether activity counts as active exploitation, leave the ticket alone rather than escalating on a weak signal.

Before escalating any ticket, check its existing comments with Get Comments to see whether this workflow already escalated it. Every comment I post should carry a consistent marker line so it is easy to find later, something like "GreyNoise exploitation escalation" as the opening line. If such a comment exists and is dated within the last seven days, skip that ticket entirely and do not include it in the summary, so the same CVE does not get re-flagged every single morning.

For each ticket that does qualify, use Jira's Edit Issue to raise the priority. Move it to High, or to the highest priority level when GreyNoise shows widespread or rapidly escalating activity. Then use Add Comment to record the evidence in plain language, written so somebody skimming the ticket next week understands it without going back to the source: what changed, when GreyNoise first saw the activity, what that activity looks like, and why this jumped the queue ahead of the rest of the backlog. Reference the specific CVE and state the old and new priority.

Never quietly downgrade a ticket. Only ever raise priority, never lower it. Exploitation going quiet is not a reason to deprioritize a patch, because the underlying vulnerability is still unpatched and activity can resume at any time. If a previously escalated CVE has gone quiet, leave the ticket exactly where it is.

Finish with one Slack message via Send a Message to my security channel, summarizing only the tickets that were escalated this morning. Give each one a single line with the ticket key, a short description of what it patches, the CVE, the old and new priority, and a direct link to the ticket. Keep it scannable rather than writing paragraphs, since the detailed reasoning already lives in the ticket comment. Post exactly one message, not one per ticket.

On days when nothing was escalated, post nothing at all. No all-clear message and no empty summary, so that any message appearing in the channel always means something genuinely changed. The one exception is failure: if the GreyNoise lookups error out or the plan does not permit CVE access, post a short note saying the sweep could not complete, so that silence always means "nothing to escalate" and never means the workflow broke without anyone noticing.